Decision on PEP 690 - Lazy Imports
The Python Steering Council has decided to reject PEP 690 on Lazy Imports.
We agree with the widely accepted sentiment that faster Python startup time is desirable. Large command line tools in particular suffer as that is a human user experience. Lazy imports, as proposed, are one of many potential mechanisms that can help with that.
But a problem we deem significant when adding lazy imports as a language feature is that it becomes a split in the community over how imports work. A need to test code both ways in both traditional and lazy import setups arises. It creates a divergence between projects who expect and rely upon import time code execution and those who forbid it. It also introduces the possibility of unexpected import related exceptions occurring in code at the time of first use virtually anywhere. Such exceptions could bubble up from transitive dependency first use in unanticipated places.
A world in which Python only supported imports behaving in a lazy manner would likely be great. But we cannot rewrite history and make that happen. As we do not envision the Python langauge transitioning to a world where lazy imports are the default, let alone only, import behavior. Thus introducing this concept would add complexity to our ecosystem.
We also discussed specific implementation details of this PEP that many of us did not really like, but ultimately decided that even with mere internal implementation changes it didn’t change our broader feeling on the matter: The complexity of fragmentation was bad and we were going to say “no” regardless.
Thank you everybody for the very thorough proposal and multiple #15474 discussions #19661 that helped inform this decision.
signed,
Your Python Steering Council, soon to be vintage 2022 edition