I generally don’t mind Python growing new features that help someone’s use case, even if I don’t personally need or use those features. If I want to, I can “opt out” of the walrus operator, or pattern matching, or other such features by just not using them. This, though, doesn’t have an “opt out” – if I don’t support it in code I write, I’ll get a steady stream of “please support lazy import” requests until I do. And I’m not sure how I feel about a feature with that level of intrusiveness.
This feature is opt-in. From the “specification” section:
Lazy imports are opt-in, and they can be globally enabled either via a new -L flag to the Python interpreter, or via a call to a new importlib.set_lazy_imports() function.
In the situations where I’ve had to be more mindful of start-up performance I’ve just opted for the manual inline approach that was shown, so I’m not all that bothered that the PEP was rejected as I, too, agree that it would most likely serve as another point of fragmentation in the community, and in all honesty continue to go against the “There should be one– and preferably only one –obvious way to do it” principle from the Zen of Python.
It sounds like the C++ problem that gets cited in Go talks. If your imports repeatedly got the same file, and you didn’t practice good strict hygiene in your compilation units, your compile times would steadily increase while the compiler wrangled your header files over and over and over again.
It sounds like meta includes the same stuff repeatedly, hurting startup. Python makes it a little worse by allowing you to run code at import time, but maybe this is something fixable with better hygiene, and not risking the strain on the ecosystem.
I generally don’t mind Python growing new features that help someone’s use case, even if I don’t personally need or use those features. If I want to, I can “opt out” of the walrus operator, or pattern matching, or other such features by just not using them. This, though, doesn’t have an “opt out” – if I don’t support it in code I write, I’ll get a steady stream of “please support lazy import” requests until I do. And I’m not sure how I feel about a feature with that level of intrusiveness.
This feature is opt-in. From the “specification” section:
In the situations where I’ve had to be more mindful of start-up performance I’ve just opted for the manual inline approach that was shown, so I’m not all that bothered that the PEP was rejected as I, too, agree that it would most likely serve as another point of fragmentation in the community, and in all honesty continue to go against the “There should be one– and preferably only one –obvious way to do it” principle from the Zen of Python.
It sounds like the C++ problem that gets cited in Go talks. If your imports repeatedly got the same file, and you didn’t practice good strict hygiene in your compilation units, your compile times would steadily increase while the compiler wrangled your header files over and over and over again.
It sounds like meta includes the same stuff repeatedly, hurting startup. Python makes it a little worse by allowing you to run code at import time, but maybe this is something fixable with better hygiene, and not risking the strain on the ecosystem.