PEP 690: Lazy Imports

[carljm (Carl Meyer)]

Hi David,

Thanks for your feedback. I think this PEP has both sizable pros (dramatic performance and memory improvements are the most notable) and sizable cons (if lazy imports are widely used, there will be two significantly different semantics for Python imports in wide use, which increases the complexity of the ecosystem.)

It’s worth reiterating that the “lazy imports” semantics are already available in the standard library today (via importlib.LazyLoader) in a very similar global opt-in way, so the PEP doesn’t introduce that, but it does make it more usable and more effective and faster, which may make it more popular, which (if it happens) means Python library maintainers are more likely to hear about it than they are today.

@davidism

• How is this going to be communicated to users, and what will they have to do to take advantage of it?

The -L flag and the new importlib.set_lazy_imports() API will be documented in the Python documentation. Their documentation will include a clear description of what they do, probably based on what can currently be found in the (newly updated and greatly expanded based on this discussion thread) PEP text. The PEP also now specifies that:

The documentation should also clarify that opting into lazy imports is opting into a non-standard semantics for Python imports, which could cause Python libraries to break in unexpected ways. The responsibility to identify these breakages and work around them with an opt-out (or stop using lazy imports) rests entirely with the person choosing to enable lazy imports for their application, not with the library author. Python libraries are under no obligation to support lazy import semantics. Politely reporting an incompatibility may be useful to the library author, but they may choose to simply say their library does not support use with lazy imports, and this is a valid choice.

@davidism

• What extra work will maintainers have to do, including learning, one time changes, and ongoing testing/maintenance?

The only extra work that maintainers have to do is possibly occasionally closing an issue with a polite “I’m sorry, I don’t support lazy imports, if you use them you’ll have to figure things out yourself.” (As Paul says, I don’t pretend that this isn’t in itself a cost; I know it is. But it’s the minimal cost that allows the feature to exist!)

If a maintainer wants to do more than that to support lazy imports, it’s a little hard to say what exactly that would entail, because it heavily depends on the details of the library. For most libraries, no code changes would be called for at all. (“Most” is supported by real-world experience here, since we have lots of Meta code using lazy imports and using many popular Python libraries.) One thing that it could entail would be choosing to run the library’s CI with lazy imports enabled (and then adding one import-the-library smoke test without lazy imports to ensure there aren’t import cycles.) It might entail an additional note in the library’s documentation that “if this feature is used in this way with lazy imports, you’ll need an opt-out.” Or it could entail code changes to reduce the library’s reliance on import side effects.