PEP 810: Explicit lazy imports

[DavidCEllis (David Ellis)]

@thomas

@DavidCEllis

Was it ever considered to use a context manager instead of new syntax?

• The previous PEP proposed adding an eager_imports manager to importlib as an opt-out so I was wondering if a lazy_imports manager was ever considered as the mechanism for an opt-in instead of new syntax.

That wouldn’t fix the issues with the existing context-manager based solutions. A hybrid where the syntax this PEP used is based on with would open a whole new world, since with has never been semantically important to the compiled code, which is quite a big lift. I’ve added it to rejected ideas, but if you want to propose a competing PEP with that syntax, feel free

I don’t think the “competing PEPs” model is a good idea. What I want is for there to be one best PEP which has carefully considered the alternatives and has the greatest chance of getting this incredibly useful feature into the language in the best way possible.

---

I hope you understood that the main purpose of this was to avoid the ugly __lazy_modules__ work-around for older Python. Although syntactically I also prefer one with statement and indentation to repeated lazy on each line as it encourages grouping the lazy imports and not scattering them between other imports.

The problems I have with writing an existing context manager version are that:

1. Reification doesn’t exist and is necessary to convert the proxy objects cleanly to the real objects
2. I’m not aware of a safe way to temporarily change the meaning of the import statement.

I wanted to experiment with the __lazy_import__ function to see if it could be used to provide an (unsafe) context manager, but it doesn’t seem to work like I would expect. sys.lazy_modules, mentioned as part of the mechanism also doesn’t appear to exist (yet?).

>>> unittest = __lazy_import__("unittest")
>>> unittest
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    unittest = __lazy_import__("unittest")
ImportError: deferred import of 'unittest' raised an exception during resolution

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    unittest
TypeError: 'module' object is not callable