PEP 810: Explicit lazy imports

I was told asked at the core dev sprints to comment due to spending way too much time thinking about this as the author of importlib and importlib.util.LazyLoader. Basically I like it and support it!

I honestly only have a couple of comments about flow in the PEP and one misunderstanding.

it is useful to provide a mechanism to activate or deactivate lazy imports at a global level.

This is the first mention of the global on/off mechanism, and it’s after emphasizing how lazy import is local. It probably could either use more details or just a “more later” comment.

will check the global lazy imports flag

First mention of the flag with no context.

the lazy imports filter

First mention of the filter with no context.

ImportError: deferred import

This is a terminology flip from “lazy” to “deferred”. For consistency it’s probably best to use the same term as the keyword in the exception message (I leave it to the PEP authors which term to choose :wink:).

No ongoing performance penalty unlike importlib.util.LazyLoader.

This assertion is made twice in the PEP and it’s actually incorrect. LazyLoader replaces __class__ for the module so that __getattribute__ gets changed to ModuleType (or whatever loader.create_module() returns so there is no perpetual performance penalty:

The key benefit of this PEP over LazyLoader is:

  • It doesn’t require wrapping import machinery to make it work.
  • It makes finding the module lazy (LazyLoader is eager in finding the module but lazy for loading).
  • It works on submodules.
12 Likes