I've got my reservations about lazy imports, but scipy in particular is such a memory hog, I've increasingly been vendoring smaller utilities out of it. Good lazy imports would be a big help.
doesn't `from scipy import ...` help with memory?
[dead]
Working to Make Python Lazy
11–20 of 21 posts
Re: Working to Make Python Lazy
#12Good feature but god I hate there’s a whole new keyword for a minor modification on an existing concept. Very unnecessary.
It's a soft keyword: https://docs.python.org/3.15/reference/lexical_analysis.html...
> As soft keywords, their use in the grammar is possible while still preserving compatibility with existing code that uses these names as identifier names.
Re: Working to Make Python Lazy
#13This seems like an ugly hack. We really need a way to snapshot a python program after its imports have been loaded, similar to temacs/emacs that's been around for decades, or a similar thing that exists in gforth. Emacs's old unexec scheme became unmaintainable but maybe there are still good alternate ways to do it.
Re: Working to Make Python Lazy
#14Is there a language with a hybrid laziness approach? similar to "do work only if needed" but if you have ressources, do work most likely to be needed, like lazy anticipating?
Re: Working to Make Python Lazy
#15Or just use C++. The Python ecosystem is just bloat, blogs and tools.
Re: Working to Make Python Lazy
#16Earlier quoted context omitted.
What is the right way to handle an optional dependency?
I think this import flow tends to be the canonical one. I might recommend doing something like importing from something like `numpy.version` (or some other "random" very small utils package) so that the work done on file load is still fairly small.
It's not clear such a thing even exists in general though. It's certainly not guaranteed by packages.
What would that be for numba?
Re: Working to Make Python Lazy
#17Earlier quoted context omitted.
...crash? Seriously: crash if your dependencies aren't available. There are better ways to do optional dependencies. ImportError ain't it.
What is the right way to handle an optional dependency?
Re: Working to Make Python Lazy
#18Earlier quoted context omitted.
What is the right way to handle an optional dependency?
I think this import flow tends to be the canonical one. I might recommend doing something like importing from something like `numpy.version` (or some other "random" very small utils package) so that the work done on file load is still fairly small.
Common? Yes. Canonical/ideal? No. Optional dependency specifiers in your package metadata is a much better way to go. You can use those even if you don't publish your package as an artifact; `pip install -e .[optional-thing]` should work, or can be made to, easily.
Re: Working to Make Python Lazy
#19Earlier quoted context omitted.
What is the right way to handle an optional dependency?
https://packaging.python.org/en/latest/guides/writing-pyproj...
I don't understand, sorry. How does declaring an optional dependency in a toml file solve the problem of accessing the symbol in your code?
Also, you need something that works for simple one-file scripts, not just a whole package or project.
Re: Working to Make Python Lazy
#20Earlier quoted context omitted.
I think this import flow tends to be the canonical one. I might recommend doing something like importing from something like `numpy.version` (or some other "random" very small utils package) so that the work done on file load is still fairly small.
Common? Yes. Canonical/ideal? No. Optional dependency specifiers in your package metadata is a much better way to go. You can use those even if you don't publish your package as an artifact; `pip install -e .[optional-thing]` should work, or can be made to, easily.
That's only part of the puzzle. Your program needs to branch on whether the dependency is installed or not!
"Oh you don't have optional dependency? Then do X" needs to happen at runtime right?