This isn’t an argument against the standard way of doing things, it is an argument to follow the xdg standard, and use xdg environment variables, rather than creating a new unconfigurable directory in $HOME.

Without knowing more, I would expect it is a dataloader issue: your CPUs are bottlenecked trying to get enough data to your GPUs.

You can add more workers to your dataloader in order to paralyze it, though this can lead to weird parallelization bugs sometimes, so if things start acting weird, that might be a reason.

Yea, it is losing the forest for the trees. Next should be taught as part of iterators and for loops. It makes sense there. It doesn’t really stand on its own much.

To be honest, I’m not sure why it is a built in function… I feel like saying that python calls the ‘next’ function of your class when iterating is enough. But maybe I’m missing something.

All ‘next’ does is call ‘next’, which is part of the spec for ‘iterator’s.

Iterables return iterators when ‘iter’ is called on them. So they don’t need to support ‘next’ natively, their corresponding iterator does that.

The value of cargo and go tools doesn’t come from the all-in-one nature of them, it comes from the official nature of them.

If something doesn’t work with cargo, it is a bug. Period. There isn’t any “it works with pip” back and forth arguing over whose fault it actually is (package? Or poetry/pipenv/pip-tools/conda/etc? This happened with pytorch a while ago, and I’m not sure if poetry and pytorch get along even now)

There also isn’t any debate over project files or configuration stuff — Pyproject.toml vs setup.cfg vs random dot files in the project directory — if you are a currently developed project you support whatever cargo supports and you move to support the latest format rather than dragging your feet for years (pyproject.toml has been the “next thing” for python since 2016! And is only finally getting widespread support now… 7 years later).