PEP 690: Lazy Imports Again

[carljm (Carl Meyer)]

@csm10495

Part of me wonders if an alternative here is to encourage imports within the function of use… I mean its sort of against the general idea of putting imports at the top, etc… though: it’s lazy… and i’ve seen it done today in some code bases with a particular module that takes a long time to import.

I’m not really saying this as a good idea, but it was rather thought-provoking to me.

Edit to add: After all: aren’t lazy imports basically syntactic-sugar around only doing the actual import once needed instead of on module import?

Yes. Per-import-statement opt-in laziness is (basically) syntactic sugar for manually inlining imports.

The main reasons to look beyond manual inlining as a solution, off the top of my head, are:

1. Manual inlining invokes the import system every time the function is called, which has a noticeable cost. The PEP 690 approach reduces this overhead to zero, after the initial reference that triggers the import.

2. Manual inlining is verbose. Sometimes syntactic sugar tastes sweet

3. Manual inlining doesn’t put the name in module scope, which means e.g. it can’t be re-exported, and it can’t be used for module-level uses like type annotations (which has a lot of value when the annotations themselves are lazy via PEP 563 or 649.)