This will be huge at the place I work! I’m unfamiliar with the PEP process. How long until this makes it into a Python version?
It should land in 3.15, so October next year. https://peps.python.org/pep-0790/
Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
21–30 of 64 posts
Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
#22This is great for building modules. One can now lazy import all interesting names on __init__.py, so that instead of having to remember `from module.some_submodule_that_you_need_to_remember import method` you can just do `from module import name`.
Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
#23I've noticed that instead of defining requires at the top of Lua files, if you can know your own program well enough, defining them right before the dependency is actually used makes large Lua programs much, much quicker. Generally speaking, startup times can be a sped up by a meaningful factor. I suspect this change in Python will dramatically improve the performance of such large programs as well.
> I suspect this change in Python will dramatically improve the performance of such large programs as well. Makes packaging super fun too, where you need to hit every possible path so you don't miss anything imported in 1% of the execution paths :)
Or, you could just use a project-level specification file to list dependencies rather than looking for imports in the code, trying to figure out what they resolve to, and trying to package the results.
Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
#24Earlier quoted context omitted.
> I suspect this change in Python will dramatically improve the performance of such large programs as well. Makes packaging super fun too, where you need to hit every possible path so you don't miss anything imported in 1% of the execution paths :)
I can't even express how negatively I feel about build/packaging systems that process dependencies based on code-level imports instead of some explicit build manifest separate to the code.
You and me both, but life as a consultant/freelancer requires you to drag yourself through dirt sometimes to make it out on the other side.
Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
#25Source link indicating PEP 810 was accepted:
https://discuss.python.org/t/pep-810-explicit-lazy-imports/1...
Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
#26Some folks at HRT[0] will probably be unhappy about that lol 0. https://www.hudsonrivertrading.com/hrtbeat/inside-hrts-pytho...
Look at the names in the PEP [1], this PEP is written by them
Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
#27This is great for building modules. One can now lazy import all interesting names on __init__.py, so that instead of having to remember `from module.some_submodule_that_you_need_to_remember import method` you can just do `from module import name`.
https://peps.python.org/pep-0810/#what-about-star-imports-fr...
> What about star imports (`from module import *`)?
> Wild card (star) imports cannot be lazy - they remain eager. This is because the set of names being imported cannot be determined without loading the module. Using the lazy keyword with star imports will be a syntax error. If lazy imports are globally enabled, star imports will still be eager.
Additionally, star imports can interfere with type checkers and IDEs and shadowing caused by star imports is a frequent and difficult to diagnose source of bugs (you analyze the function you think you're calling and find no issues, but you're actually calling a different function because the star import occurs after your explicit import).
You might be able to workaround this limitation by doing a lazy import into an intermediate module (a prelude) on a name by name basis and then star import that intermediate module. But personally I solve this problem using IDE features.
https://github.com/python-lsp/python-lsp-server/blob/develop...
Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
#28Next we need
lazy import *Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
#29I think HN is translating the link somehow? It should be directing to this post: https://discuss.python.org/t/pep-810-explicit-lazy-imports/1... """ Dear PEP 810 authors. The Steering Council is happy to unanimously [4 votes, as Pablo cannot vote] accept “PEP 810, Explicit lazy imports”. Congratulations! We appreciate the way you were able to build on and improve the previously discussed (and rejected) attempt at laz…
[flagged]
Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"
#30Earlier quoted context omitted.
> I suspect this change in Python will dramatically improve the performance of such large programs as well. Makes packaging super fun too, where you need to hit every possible path so you don't miss anything imported in 1% of the execution paths :)
Can't you do some kind of static analysis instead?
Depends if your code has horrors like this lurking in it:
m = importlib.import_module(requests.get("http://localhost:8000/package_name").content.strip().decode("ASCII"))