Rendered at 04:59:16 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dataflow 1 days ago [-]
> This pattern, for example, can’t be lazy: try: import numpy; except ModuleNotFoundError: ...
Wait, that seems bad. These kinds of modules (especially numba) are often exactly the ones that you want to delay importing. Why not provide a way to check the existence at import time? How are you supposed to handle nonexistence in that case?
js2 1 days ago [-]
> The error here will move to the first usage of something from numpy. There is a semi-lazy alternative:
import importlib.util
if importlib.util.find_spec("numpy") is None:
... # whatever you wanted to do if numpy is missing
lazy import numpy
zbentley 1 days ago [-]
...crash?
Seriously: crash if your dependencies aren't available. There are better ways to do optional dependencies. ImportError ain't it.
dataflow 1 days ago [-]
What is the right way to handle an optional dependency?
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.
rtpg 1 days ago [-]
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.
zbentley 16 hours ago [-]
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.
dataflow 16 hours ago [-]
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?
mhashemi 1 days ago [-]
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.
wodenokoto 1 days ago [-]
doesn't `from scipy import ...` help with memory?
stevesimmons 20 hours ago [-]
[dead]
throwaway81523 18 hours ago [-]
This 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.
yuriks 1 days ago [-]
This feature seems really valuable for commandline tools! However this paragraph gave me pause:
> Currently, disabling lazy imports disabled the syntax keyword, which means that you can’t use it for circular imports, type checking, etc.
Imo this is a good thing, laziness shouldn't be semantically important. The ability to force disable laziness while maintaining semantics is important for linting and testing, and more often than not, circular imports are a sign of bad code structure.
disdegeneration 17 hours ago [-]
Is 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?
nxtfari 24 hours ago [-]
Good feature but god I hate there’s a whole new keyword for a minor modification on an existing concept. Very unnecessary.
> As soft keywords, their use in the grammar is possible while still preserving compatibility with existing code that uses these names as identifier names.
4563lk 17 hours ago [-]
Or just use C++. The Python ecosystem is just bloat, blogs and tools.
Wait, that seems bad. These kinds of modules (especially numba) are often exactly the ones that you want to delay importing. Why not provide a way to check the existence at import time? How are you supposed to handle nonexistence in that case?
Seriously: crash if your dependencies aren't available. There are better ways to do optional dependencies. ImportError ain't it.
Also, you need something that works for simple one-file scripts, not just a whole package or project.
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.
What would that be for numba?
> Currently, disabling lazy imports disabled the syntax keyword, which means that you can’t use it for circular imports, type checking, etc.
Imo this is a good thing, laziness shouldn't be semantically important. The ability to force disable laziness while maintaining semantics is important for linting and testing, and more often than not, circular imports are a sign of bad code structure.
> As soft keywords, their use in the grammar is possible while still preserving compatibility with existing code that uses these names as identifier names.