PEP 810: Explicit lazy imports

[MegaIng (Cornelius Krupp)]

@csm10495

If I lazy import something that would have previously been a recursive import cycle, would that now be allowed if the recursive import cycle has a lazy in the middle?

Assuming lazy imports aren’t disabled, it would probably no longer cause issues since the import doesn’t actually happen at that point in time.

The PEP explicit suggests not starting to rely on this and instead to still refactor the code to not have circular dependencies. Whether or not this advice will be followed in practice is to be seen.

[tinchit0 (Martín H. Campos)]

Hi all. Love the PEP.

So what’s the current status regarding using lazy imports for optional dependencies? Will lazy be the way to go? It still seems very valuable to have a mechanism that allows importing optional packages in the top of the module without raising ModuleNotFoundError on installations where they’re missing.

After thinking about it, I feel the “optional import” use case might be orthogonal to “lazy import”: maybe you are okay with it being lazy, but maybe you want it to be eager. Perhaps this deserves a separate proposal — introducing an optional modifier, similar in spirit to lazy, but focused on optionality rather than deferral.

Would it make sense to open a new discussion thread to explore whether such an idea could justify its own PEP?

[oscarbenjamin]

@tinchit0

It still seems very valuable to have a mechanism that allows importing optional packages in the top of the module without raising ModuleNotFoundError on installations where they’re missing.

The lazy import added here is not directly suitable for this because it means that any place you use the imported name can trigger reification so you would have to guard for ImportError everywhere rather than just in one place. Also you would often want to be able to know ahead of time whether the optional dependency is available.

Way up at the top of this thread this was discussed and you could do something like this:

from typing import TYPE_CHECKING
import importlib.util

if importlib.util.find_spec("numpy") is not None or TYPE_CHECKING:
    lazy import numpy as np
    using_numpy = True
else:
    using_numpy = False

def some_func():
    if not using_numpy:
        raise ImportError("Install numpy for this")
    # reification here will succeed:
    return np.arange(10)

The find_spec call accesses the file system so is not fully lazy but it is much faster than actually importing numpy so if the optional dependency is not used at runtime the import overhead can be mostly avoided.

[MegaIng (Cornelius Krupp)]

@tinchit0

So what’s the current status regarding using lazy imports for optional dependencies? Will lazy be the way to go? It still seems very valuable to have a mechanism that allows importing optional packages in the top of the module without raising ModuleNotFoundError on installations where they’re missing.

• You are not guaranteed that the import will be lazy - this is why the PEP says “potentially lazy import”.
• If you do import it lazy, usages of the symbol starts raising ImportError - this is probably not what you want.

So no. It’s generally not the way to go.