First of all, I think there is real value in lazy imports, and in adding them to the language rather relying on various third-party implementations.
However the proposed PEP just feels too magical. Controlling import by configuration, rather than being explicit,
makes it really hard to reason about and test code.
I don’t think that having things that do or don’t exist, depending on how you look at them, is a good idea.
(I’m referring to the hidden thunks that a lazy import introduces).
I feel that explicit approaches have been rejected with insufficient justification.
Using an explicit lazy as a keyword prefix to import makes it very clear what is going on, and allows packages precise control over what they import lazily and what they import eagerly, and the ability to test their packages properly.
lazy import mod
could simply create a lazy module object that would convert itself into a real module (performing the import) when it was used.
I understand the desire to force packages to be loaded lazily in a large application, rather than waiting for package maintainers to implement it themselves, which might take years.
However, if the feature is as valuable as claimed, package maintainers will be eager to adopt it.
The PEP as proposed has too many rules as to when a module is imported lazily or not. It is impossible to know at a glance whether a module will be loaded eagerly or lazily. A keyword makes it very clear.
One thing that this PEP does that an explicit lazy import could not is defer the loading of a module when an attribute is accessed from it without changing the class of that attribute, so this
from mod lazy import foo
can only work if foo is a module.
However, if lazy imports are wanted, then changing to code to
lazy import mod
and changes uses of foo to mod.foo doesn’t seem a big deal.