PEP 690: Lazy Imports

[ronaldoussoren]

@carljm

@ronaldoussoren

The PEP mentions that importing inside a try-except block makes the lazy import eager. Is that intended to be recursive, or does it only apply to the imports mentioned in the block?

It is shallow. If it were transitive, this makes it impossible to reason locally about the laziness of any given import. Rather than just looking at the import itself and the global configuration of lazy imports, now you have to understand every possible import chain (all the way to the top) that could ever reach this import, in order to know whether it will be lazy. And it means that putting the wrong import inside a try could unexpectedly render most of the codebase eagerly imported.

I’m liking this proposal less and less. As a library author I’d already have to reason about the possible effect of lazy imports and disabling being shallow means I have to know about internal details of the libraries I import to do this analysis.

I’m already not a fan of implicit lazy import due to import errors popping up when trying to use the imported module instead of at the import statement itself. That said, I’m not in the target audience of this proposed feature.

@carljm

@ronaldoussoren

The latter could be problematic for code trying to deal with missing dependencies of imports

Yes, this can be a problem. It would not actually impact the curses module, since Lib/curses/__init__.py has from _curses import * , which is always eager since it is a star import. Although this is somewhat accidental in this case, it does reflect the right way to handle a case like this: just ensure the import that might fail is eager, using any of the methods the PEP provides for that.

The debugging of this scenario is reasonable. Assuming it did impact curses : if you enable lazy imports for your application, when you test it on a system without curses, you would get a LazyImportError showing the import of _curses that failed, with a traceback showing the import was triggered at the first place that name is used. Then you add curses to the lazy imports opt-out list for your application and move on.

I’d probably end up adding a pth file that automates this to libraries that are be affected by this feature…