Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

Posted by Redoubts 2 days ago

Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"(discuss.python.org)

167 points | 60 commentspage 2

curiousgal 1 day ago|

Some folks at HRT[0] will probably be unhappy about that lol

0.https://www.hudsonrivertrading.com/hrtbeat/inside-hrts-pytho...

CorrectHorseBat 1 day ago||

Look at the names in the PEP [1], this PEP is written by them

[1] https://peps.python.org/pep-0810/

seemaze 1 day ago|||

I'm confused, wouldn't HRT be happy about this? The article you linked specifically states "..we hope to propose a revised lazy imports PEP that introduces an explicit lazy keyword.."

Is that not exactly what PEP 810 proposes?

kccqzy 1 day ago||

Why would they? The accepted PEP just has extra keywords to mark imports explicit. That's a source level find-and-replace. They already did most of the real work in their codebase, such as finding where the code depended on the side effect of importing a module.

andrewmcwatters 1 day ago||

I'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.

embedding-shape 1 day ago||

> 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 :)

KptMarchewa 1 day ago|||

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.

embedding-shape 1 day ago|||

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.

jacquesm 1 day ago|||

Not to mention the potential for runtime errors long after the code has started up.

dragonwriter 1 day ago||||

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.

snovv_crash 1 day ago|||

Can't you do some kind of static analysis instead?

Figs 1 day ago|||

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"))

falcor84 1 day ago|||

If you want even better nightmares, you can make localhost:8000 forward to a container running claude code with --dangerously-skip-permissions which uses an unkindness of mcp servers to control that endpoint on the fly based (amongst other sources) on 4chan's /b/.

zahlman 1 day ago|||

> which uses an unkindness of mcp servers

I guess you meant "a feature of MCP servers which is unkind", but I couldn't help but interpret "unkindness" as the collective noun for a group of MCP servers.

falcor84 1 day ago||

That was indeed the intent. I first considered "a conspiracy" like with lemurs, but eventually felt that "unkindness" was more appropriate.

snovv_crash 1 day ago|||

Better to let the viewers on a twitch stream vote for it.

im3w1l 1 day ago|||

Since this should be a rare thing I don't think it's unreasonable to require users of patterns like this to put some kind of special annotation for that static analysis tool saying "it may not look like it but I'm doing an import here".

fithisux 1 day ago|||

Yes. It is much more clear to be explicit though.

jacquesm 1 day ago||

Safer too.

markrages 1 day ago||

You have always been able to do the same thing in Python. This PEP isn't needed for that functionality.

andrewmcwatters 1 day ago|||

Yeah, I'm aware the same behavior is available, but this proposal creates a call trigger on the dependency which requires far less analysis on larger projects to understand where the import needs to be moved to.

You have to create wrappers in languages like JavaScript, Lua, Python, etc. to create the same behavior.

skywhopper 1 day ago|||

You can declare imports at the beginning of a program that don’t load until they are used?

markrages 1 day ago|||

"defining them right before the dependency is actually used"

xenator 1 day ago||

Does it conform Occam's razor rule to have something that can be easily done very similar way without changing language?

boothby 1 day ago||

Having some limited experience with lazy imports, yes, but this eliminates a lot of gross boilerplate. It also has the effect of "blessing" the practice of lazy imports which can have a cultural impact; it also prevents a situation wherein multiple subtly incompatible approaches to lazy imports become individually popular.

contravariant 1 day ago||

Not sure that's Occam's razor any more.

Regardless lazy loading needs widespread use to be most effective so having a unified syntax and no extra dependencies makes a lot of sense.

manbitesdog 1 day ago|

This 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`.

maxbond 1 day ago|

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...

manbitesdog 5 hours ago||

? This has nothing to do with star imports