GeezerVison

lazy import a.b as c binds c to a.b.b instead of the module a.b when a.b is already in sys.modules and has an attribute named b.

Root cause

import a.b as c compiles to IMPORT_NAME a.b followed by IMPORT_FROM b. For a lazy import, IMPORT_NAME returns a placeholder with lz_from = "a.b".

_PyEval_LazyImportFrom() has a fast path for modules already in sys.modules. It looks up lz_from directly and gets name from that module. In this case that means looking up b on a.b, producing a.b.b, instead of looking up b on the base module a.

Fix

Compute the base module before the sys.modules fast path and perform the lookup against it.

The fast path must also be limited to the last IMPORT_FROM identifiable from the placeholder. Longer dotted names compile to multiple IMPORT_FROM instructions, and resolving an intermediate step would make the rest of the import eager. Eight existing test_lazy_import tests cover this.

Two-component imports and from imports remain eligible for the fast path.

Test

Adds MixedLazyEagerImportTests.test_eager_dotted_import_before_lazy_resolves_to_same_module() alongside the existing single-name test.

It creates a package a with a/b.py defining an attribute b, then checks:

import a.b as c
lazy import a.b as lazy_c

assert lazy_c is c

The test fails on main because lazy_c resolves to a.b.b and passes with the fix. test_lazy_import, test_import, and test_importlib also pass.

Commits

1. Move the lazy import subprocess helpers to LazyImportTestCase so the regression test can reuse them. No behavior change.
2. Fix _PyEval_LazyImportFrom(), with the regression test and NEWS entry.

Future Work / Not Addressed

If package a itself has an attribute b shadowing submodule a.b, the lazy import can still reify to that attribute rather than the submodule. This is a separate mechanism, already tracked in gh-151208. The same mechanism makes lazy import math.pi as x bind the float where the eager statement raises; gh-155194 fixed the bare lazy import math.pi form only.

For names with three or more components, an already-loaded module still resolves on first use rather than at the import statement because later IMPORT_FROM steps cannot tell whether they are the last one. Fixing that would require additional compiler or placeholder information and is only an optimization.

Closes gh-157614.