PEP 810: Explicit lazy imports

PEPs
77

Thanks for making the PEP. This looks much improved compared to the previous attempt at a lazy import system with PEP 690.

I ended up rolling my own lazy importer for use with my own CLI tools and it would be nice to be able to replace this. I’ve measured this making short-lived CLI tools run in half the time for some tasks so having this as a built-in feature is definitely worthwhile.

A few questions:

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

  2. You briefly mention considering using a subclass of dict to enable lazy imports, but with the mention of calling __getitem__ directly I’m a little confused as to how it was consiidered.

    • My expectation would have been that a __missing__ method could be used to check if an absent name was a lazy import, which would be supported by __getitem__, is there a reason this is not the case?

  3. I understand why the try/except syntax can’t be supported directly by syntax, but is it possible to have some other way of supporting the concept by providing a way to embed the try/except logic inside the proxy object that would execute on reification?

    • Alternatively, for the case of try/except as existence check, could there be a helper “module_exists” function that can be used to convert from a try/except into an if/else that can be used with the lazy import form?

  4. It’s possible to globally opt-out with -X lazy_imports="disabled", presumably this will cause a module import to fail if a lazy import has been used to hide a circular import?

    • Might it be necessary to add a filter to opt-in for specific modules in the same way modules can opt-out of being lazily imported under -X lazy_imports="enabled"?
1 Like