PEP 690: Lazy Imports

[carljm (Carl Meyer)]

@malemburg

The failing import could in fact be a lazy top-level import somewhere deep inside a package that you import with try-except, so the eager import you are forcing at the higher level doesn’t protect the lazy import which is done a few levels deep and the ImportError would not bubble up the stack.

In theory, sure. In practice I’m not sure I’ve ever seen a try/except around an import that wasn’t intending to catch the non-presence of the immediately imported module. Do you have a real-world counter-example?

@malemburg

Lazy imports are good way to achieve better startup time, but this feature should not be a global setting of the interpreter.

I think a key question is whether the robust startup time and memory benefits of PEP 690 are realistically ever achievable without allowing the application developer to control it globally for their application. There is a collective action problem here. There is very little incentive for any given library to bother marking themselves as “lazy import safe,” especially the many libraries which receive only bare-bones maintenance at all. And there’s less value for an application developer in lazy imports if none of their libraries can be lazy imported.

Also, as I already discussed above, the idea of libraries marking themselves “lazy import safe” is itself overly simplistic and not sufficient to guarantee to an application developer that nothing will break with lazy imports.

I don’t think there is any way to provide lazy imports in Python that can ever be 100% transparently guaranteed to not break anything when adopted, so if that’s the bar for an opt-in feature, we may as well just say that we will never provide it. (Which would be odd, considering that the standard library already provides global opt-in lazy imports via LazyLoader, with fewer benefits but all the same potential problems that have been discussed in this thread. Should it be removed? Would PEP 690 be more acceptable if it were simply an improvement to the already-existing LazyLoader to reduce its overhead and allow it to make a few more styles of imports lazy, but installing LazyLoader was the only way to opt into it?)

Or we can choose the PEP 690 approach, which is to provide maximum potential benefits immediately to any application developer, with a clear caveat that it is a change to semantics and the application developer adopting it is responsible to ensure their application still works correctly with it. This seems very much in the “consenting adults” spirit.