PEP 810 – Explicit lazy imports • Hacker News Board

Re: PEP 810 – Explicit lazy imports

#31

Post by Alir3z4 » Fri, Oct 03, 2025, 7:50 PM UTC

f311a wrote: post #26

I don't like the idea of introducing a new keyword. We need a backward compatible solution. I feel like Python needs some kind of universal annotation syntax such as in go (comments) or in Rust (macros). New keyword means all parsers, lsps, editors should be updated. I’m pretty sure there will be new keywords in Python in the future that only solve one thing.

Me neither.

Introducing new keyword has become a recent thing in Python.

Seems Python has a deep scare since Python2 to Python3 time and is scared to do anything that causes such drama again.

For me, the worst of all is "async". If 2to3 didn't cause much division, the async definitely divided Python libraries in 2. Sync and Async.

Maybe if they want backward compatible solution, this can be done by some compile or runtime flag like they did with free threading no-gil.

Re: PEP 810 – Explicit lazy imports

#32

Post by simonw » Fri, Oct 03, 2025, 7:54 PM UTC

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.datasette.io/en/stable/plugins/advanced-model-pl... - but having a core Python language feature for this would be really nice.

Re: PEP 810 – Explicit lazy imports

#33

Post by aftbit » Fri, Oct 03, 2025, 7:57 PM UTC

We tend to prefer explicit top-level imports specifically because they reveal dependency problems as soon as the program starts, rather than potentially hours or days later when a specific code path is executed.

Re: PEP 810 – Explicit lazy imports

#34

Post by maest » Fri, Oct 03, 2025, 7:59 PM UTC

aftbit wrote: post #33

We tend to prefer explicit top-level imports specifically because they reveal dependency problems as soon as the program starts, rather than potentially hours or days later when a specific code path is executed.

Who is "we"?

Re: PEP 810 – Explicit lazy imports

#35

Post by sigmoid10 » Fri, Oct 03, 2025, 8:00 PM UTC

Alir3z4 wrote: post #31

f311a wrote: post #26

I don't like the idea of introducing a new keyword. We need a backward compatible solution. I feel like Python needs some kind of universal annotation syntax such as in go (comments) or in Rust (macros). New keyword means all parsers, lsps, editors should be updated. I’m pretty sure there will be new keywords in Python in the future that only solve one thing.

Me neither. Introducing new keyword has become a recent thing in Python. Seems Python has a deep scare since Python2 to Python3 time and is scared to do anything that causes such drama again. For me, the worst of all is "async". If 2to3 didn't cause much division, the async definitely divided Python libraries in 2. Sync and Async. Maybe if they want backward compatible solution, this can be done by some compile or ru…

Async or not in modules is a huge pain in the ass for web-dev, but thankfully a lot of Python still isn't web dev. As a Data Scientist you can live your life peacefully without ever worrying about this. But I can see why web devs like it, even though personally I really don't want to see anymore Javascript sneaking inty my Python. Especially when there is already support for IO bound concurrency elsewhere in the language. If I want to do JS syntax, I'll fucking use JS. And I really don't want to see Python go the C++ route where it just wants to be everything and do everything so that you end up with so many possible approaches to the same problem that two devs can't read each others code anymore.

Re: PEP 810 – Explicit lazy imports

#36

Post by bityard » Fri, Oct 03, 2025, 8:03 PM UTC

aftbit wrote: post #33

We tend to prefer explicit top-level imports specifically because they reveal dependency problems as soon as the program starts, rather than potentially hours or days later when a specific code path is executed.

I haven't fully digested the PEP but perhaps there would be a command-line flag or external tool for dependency validation, a bit like how there are external tools for type annotations?

Re: PEP 810 – Explicit lazy imports

#37

Post by ashu1461 » Fri, Oct 03, 2025, 8:06 PM UTC

f311a wrote: post #26

I don't like the idea of introducing a new keyword. We need a backward compatible solution. I feel like Python needs some kind of universal annotation syntax such as in go (comments) or in Rust (macros). New keyword means all parsers, lsps, editors should be updated. I’m pretty sure there will be new keywords in Python in the future that only solve one thing.

Not sure if this can be made backward compatible.

Right now all the imports are getting resolved at runtime example in a code like below

  from file1 import function1

When you write this, the entire file1 module is executed right away, which may trigger side effects.

If lazy imports suddenly defer execution, those side effects won’t run until much later (or not at all, if the code path isn’t hit). That shift in timing could easily break existing code that depends on import-time behavior.

To avoid using lazy, this there is also a proposal of adding the modules you want to load lazily to a global `__lazy_modules__` variable.

Re: PEP 810 – Explicit lazy imports

#38

Post by npage97 » Fri, Oct 03, 2025, 8:06 PM UTC

eesmith wrote: post #17

sedatk wrote: post #3

I wonder how much things would break if all imports were lazy by default.

All my code which uses import probing would fail, such as fallbacks: try: import module except ImportError: import slow_module as module Conditional support testing would also break, like having tests which only run if module2 is available: try: import module2 except ImportError: def if_has_module2(f): return unittest.skip("module2 not available")(f) else: def if_has_module2(f): return f @if_has_module2 class TestMod…

You have to opt in with the lazy import keyword no matter what. This pep also prevents lazy import in try catch. I think your concern matters if ‘module’ itself has a lazy import that you want to check exists. With this you now need to be more rigorous in check those sub dependencies.

This can already happen with non top level imports so it is not a necessarily a new issue, but could become more prevalent if there is an overall uptake in this feature for optional dependencies.

Re: PEP 810 – Explicit lazy imports

#39

Post by ashu1461 » Fri, Oct 03, 2025, 8:10 PM UTC

aftbit wrote: post #33

We tend to prefer explicit top-level imports specifically because they reveal dependency problems as soon as the program starts, rather than potentially hours or days later when a specific code path is executed.

Right, Not sure why but a lot of code which claude generates also comes with local dependencies vs globally declared import statements. Don't promote that pattern because

- It reduces visibility into a module’s dependencies.

- It increases the risk of introducing circular dependencies later on.

Re: PEP 810 – Explicit lazy imports

#40

Post by rplnt » Fri, Oct 03, 2025, 8:11 PM UTC

Remember mercurial? Me neither. But what I remeber is this article I've read about all the hacks they had to do to achieve reasonable startup time for CLI in python. And the no #1 cause was loading the whole world you don't ever need. As I recall they somehow monkeypatched the interpreter to ignore imports and just remember their existence until they were actually needed, at which point the import happened. So all the dead paths were just skipped.