Alternative path for explicit lazy imports

Supporting @brettcannon here, one of the things to consider is that we (in the narrow “import system maintainers and contributors” sense) have had LazyLoader in the stdlib for quite some time, along with 3rd party function based lazy loaders before that, and never promoted any of them to syntactic sugar because they failed the “too much pain for not enough expressive gain” test. Lazy loading is inherently confusing (that was a big part of the proposal to make imports lazy by default getting rejected), and existing lazy import semantics can be expressed as functions, so there’s no huge benefit to giving them dedicated syntax (aside from giving static code analysers a hint as to what is going on).

What makes PEP 810 so interesting is the fact that it not only proposes dedicated syntax, but also takes advantage of the compiler being aware of what is going on in order to offer semantics that mitigate some of the annoyances associated with using lazy imports in a way that function based proposals can’t reasonably provide.

Importantly, existing function based lazy imports continue to work as they do today, so we’re not losing any capabilities, and we’d potentially be reducing the barriers keeping folks from making effective use of lazy imports to reduce the runtime overhead of initialising irrelevant modules.

13 Likes