Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 810 – Explicit lazy imports

peps.python.org

Post reply on HN
Print view View original

221–230 of 247 posts

Re: PEP 810 – Explicit lazy imports

#221

Post by nilslindemann »

zahlman wrote: post #211
nilslindemann wrote: post #122

This is the wrong syntax, comparable to how "u" strings were the wrong syntax and "b" strings are the right syntax. They make that, what should be the default, a special case. Soon, every new code will use "lazy". The long term effect of such changes is a verbose language syntax. They should have had a period where one, if they want lazy imports, has to do "from __future__ import lazy_import". After that period, lazy…

I think your assessment of what's "the right/wrong" syntax is fair. But the transition you describe takes a long time, even now that the community has figured out a "deprecation cycle" process that seems satisfactory (i.e. won't lead to another Python 3.0 situation). > All which authors of old code would have to do is run a provided fix script in the root directory of their code. As I recall, `lib2to3` didn't do a lo…

Honestly, I don't care for 2 to 3 or six (which, btw, has just 1k stars on GitHub, compare to e.g. 90k stars for FastAPI). Someone who bases their code on 2.7 in 2025 must expect to run into trouble.

If people do not run such upgrade scripts, it must be documented better.

Python is free. In order to also stay elegant, they should say to their users: "We expect from you to run an upgrade script on your code once per Python upgrade"

Re: PEP 810 – Explicit lazy imports

#222

Post by forrestthewoods »

dataangel wrote: post #125
forrestthewoods wrote: post #22

I don’t want lazy imports. That’s just makes performance shitty later and harder to debug. It’s a hacky workaround. What I want is for imports to not suck and be slow. I’ve had projects where it was faster to compile and run C++ than launch and start a Python CLI. It’s so bad.

imports run arbitrary Python code, making them faster is the same as making every other language feature faster

Can you show me a profile that demonstrate the slowness is because imports are running large amounts of arbitrary Python code? Maybe they shouldn't do that. Maybe libraries should be pushed to not run expensive arbitrary code execution at import time.

Re: PEP 810 – Explicit lazy imports

#223

Post by Neywiny »

simonw wrote: post #32

Love this. My https://llm.datasette.io/ CLI tool supports plugins, and people were complaining about really slow start times even for commands like "llm --help" - it turned out there were popular plugins that did things like import pytorch at the base level, so the entire startup was blocked on heavy imports. I ended up adding a note to the plugin author docs suggesting lazy loading inside of functions - https://llm.…

I think really the problem is that packages like pytorch take so long to import. In my work I've tried a few packages (not AI stuff) that do a lot of work on import. It's actually quite detrimental because I have to setup environment variables to pass things that should be arguments of a setup function in. All things considered a python module shouldn't take any noticeable time to import

Re: PEP 810 – Explicit lazy imports

#224

Post by zahlman »

wslh wrote: post #216
zahlman wrote: post #62

Earlier quoted context omitted.

You can implement this from your tool today: https://news.ycombinator.com/item?id=45467489 Note that this is global to the entire process, so for example if you make an import of Numpy lazy this way, then so are the imports of all the sub-modules. Meaning that large parts of Numpy might not be imported at all if they aren't needed, but pauses for importing individual modules might be distributed unpredictably across…

Is it another potential solution (until PEP 810 is accepted) to override the NameError exception, decide if it was triggered by an unloaded package from a list, and then running again that line of code? I understand the inefficiency of this solution (e.g. the same line could trigger NameError several times and you need to run it again until all modules are loaded) but this is a good brainstorming thread.

That sounds very unpleasant. However nicely you wrapped it up, you'd still be referring to the code for that process everywhere that the NameError could occur.

Re: PEP 810 – Explicit lazy imports

#225

Post by redleader55 »

zahlman wrote: post #59

> The standard library provides the LazyLoader class to solve some of these inefficiency problems. It permits imports at the module level to work mostly like inline imports do. The use of these sorts of Python import internals is highly non-obvious. The Stack Overflow Q&A I found about it ( https://stackoverflow.com/questions/42703908/ ) doesn't result in an especially nice-looking UX. So here's a proof of concept in…

Can you explain why does "threading" needs to be loaded? The rest seems decently straightforward, but what initialization from threading is required and why only in 3.13+?

Re: PEP 810 – Explicit lazy imports

#226

Post by flare_blitz »

f33d5173 wrote: post #219
flare_blitz wrote: post #135

Earlier quoted context omitted.

I also hope this proposal succeeds, but I'm not optimistic. This will break tons of code and introduce a slew of footguns. Import statements fundamentally have side effects, and when and how these side effects are applied will cause mysterious breakages that will keep people up for many nights. This is not fearmongering. There is a reason why the only flavor of Python with lazy imports comes from Meta, which is one o…

This is a new syntax, so it is opt-in. The new syntax can be conceived as syntax sugar that lets you rewrite def my_func(): import my_mod my_mod.do_stuff() as lazy import my_mod def my_func(): my_mod.do_stuff() Ie, with lazy, the import happens at the site of usage. Since clearly this is code that could already be written, it only breaks things in the sense that someone could already write broken code. Since it is op…

This is already addressed in my comment above.

Re: PEP 810 – Explicit lazy imports

#227

Post by tomyhsieh »

charliermarsh wrote: post #21

Lazy imports have been proposed before, and were rejected most recently back in 2022: https://discuss.python.org/t/pep-690-lazy-imports-again/1966... . If I recall correctly, lazy imports are a feature supported in Cinder, Meta's version of CPython, and the PEP was driven by folks that worked on Cinder. Last time, a lot of the discussion centered around questions like: Should this be opt-in or opt-out? At what level?…

Just curious. What changed?

From merely browsing through a few comments, people have mostly positive opinions regarding this proposal. Then why did it fail many times, but not this time? What drives the success behind this PEP?

Re: PEP 810 – Explicit lazy imports

#230

Post by wmichelin »

This seems unnecessary if we can run imports from functions, right? This feels like a layer of indirection and a potential source for confusion. Rather than implicitly importing a library when the variable is first used, why don't you just explicitly do it?

Edit

> A somewhat common way to delay imports is to move the imports into functions (inline imports), but this practice requires more work to implement and maintain, and can be subverted by a single inadvertent top-level import. Additionally, it obfuscates the full set of dependencies for a module. Analysis of the Python standard library shows that approximately 17% of all imports outside tests (nearly 3500 total imports across 730 files) are already placed inside functions or methods specifically to defer their execution. This demonstrates that developers are already manually implementing lazy imports in performance-sensitive code, but doing so requires scattering imports throughout the codebase and makes the full dependency graph harder to understand at a glance.

I think this is a really weak foundation for this language feature. We don't need it.

Post reply on HN