Barry Warsaw, writing for the Python steering council, has announced that PEP 810 (“Explicit lazy imports”) has been approved, unanimously, by the four who could vote. Since Pablo Galindo Salgado was one of the PEP authors, he did not vote. The PEP provides a way to defer importing modules until the names defined in a module are needed by other parts of the program. We covered the PEP and the discussion around it a few weeks back. The council also had “recommendations about some of the PEP’s details, a few suggestions for filling a couple of small gaps”, including:
Use lazy as the keyword. We debated many of the given alternatives (and some we came up with ourselves), and ultimately agreed with the PEP’s choice of the lazy keyword. The closest challenger was defer, but once we tried to use that in all the places where the term is visible, we ultimately didn’t think it was as good an overall fit. The same was true with all the other alternative keywords we could come up with, so… lazy it is!
What about from foo lazy import bar? Nope! We like that in both module imports and from-imports that the lazy keyword is the first thing on the line. It helps to visually recognize lazy imports of both varieties.
Very cool - wonder how this might impact micropython…
YEEEEEEES
This is the kinda news want to wake up in the morning and be presented with.
This is great news, I’ve never sat down and benchmarked the importing times (I believe theres a python -X switch or similar) but the more options the merrier!
Before reading it: why not make it the default?
I read the PEP and couldn’t find why it’s a proposal for an explicit keyword only. Probably backwards compatibility, but maybe it’ll become the norm.
It wouldn’t surprise me if it became a keyword for module local things too like functions. Then it would make declaring a class that uses other classes in read order i.e class A uses class B which uses class C >>> declaration order is A, B, C instead of the current C, B, A.
Before reading it: why not make it the default?
Because it breaks a lot of things. Whether it’s good practice or not, running module code at import time may be expected to initialize some code, setup listeners, build classes etc.
And that’s actually what I want much of the time, since I’d rather pay that cost on startup than throughout a running program’s life, esp. for heavy dependencies.
So a keyword is great here, since I can balance startup time and hitching during operation.
wrong direction, we needed something like unexec to dump an image file with any currently loaded modules.
What do you mean by “image”? As in, everything currently loaded into Python? Wouldn’t that just be execing the current architecture[0] again with the same ENV vars and args?
I don’t think the env vars were dumped. Unexec only dumped out the memory region where the loaded modules were. It was very OS dependent and got harder to maintain as the number of OS variations grew, and eventually had to be replaced with something a little less efficient. But, it think it might be doable again using something like CRIU. I’ve been wanting to look into it. Another idea might be extending the marshal format to dump all the loaded modules and their data into one file for fast reloading.
