GeezerVison is showing github.com — `lazy import a.b as c` incorrectly binds to `a.b.b` · Issue #157614 · python/cpython
lazy import a.b as c incorrectly binds to a.b.b #157614
Labels 3.15bugs and security fixesbugs and security fixes3.16new features, bugs and security fixesnew features, bugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-lazy-importstype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error DescriptionBug report
(Edited by @johnslavik)
To reproduce:
import importlib.metadata
import importlib.metadata as x
lazy import importlib.metadata as lazy_x
print("type(x): ", type(x).__name__) # reifies to importlib.metadata
print("type(lazy_x):", type(lazy_x).__name__) # reifies to importlib.metadata.metadata
x.distributions() # OK
lazy_x.distributions() # AttributeError: 'function' object has no attribute 'distributions'x is the importlib.metadata module, as expected. lazy_x is instead reified to importlib.metadata.metadata, the function.
The bug is in cached name resolution.
For lazy import a.b as c, the issue reproduces when:
a.b is already in sys.modules.a.b has an attribute named b.c is reified.
Possible root cause
The problem may be in _PyEval_LazyImportFrom: [Python/ceval.c:3305-3361](https://github.com/python/cpython/blob/cf312cfa64dcaa1700531ec8bc76d56ddd65fb15/Python/ceval.c#L3305-L3361) (3.15 at cf312cfa64dcaa1700531ec8bc76d56ddd65fb15, v3.15.0rc2-22-gcf312cf).
The sys.modules fast path at lines 3313-3331 runs before the base-module computation at 3333-3360 and looks up name directly in d->lz_from.
In the IMPORT_FROM chain generated for import a.b.c as x, however, d->lz_from does not appear to be the module the attribute should be taken from: on the first step it is the full dotted name, and on later steps it is one component short of the base.
CPython versions tested on:
3.15
Operating systems tested on:
Linux
Linked PRs
Activityjohnslavik commented on Sep 16, 2026 Thanks for reporting the issue, I've reproduced it.
You've opened a PR in your fork repo, not in CPython. grgalex commented on Sep 16, 2026 ContributorAuthor More actions @johnslavik Thanks for reproducing!
Ahhh the PR on the fork references the issue so it appears here. Was testing some stuff!
I'll submit the associated PR once it's ready (soon!) :) Reacted by Bartosz Sławecki johnslavik commented on Sep 16, 2026 @grgalex In the test please create a package structure to be imported, don't rely on importlib.metadata because that API can change. We should test the pattern, not something that happens to accidentally be an instance of it today. Reacted by George Alexopoulos grgalex commented on Sep 16, 2026 ContributorAuthor More actions @johnslavik I've opened the PR.
Next time I'll make sure not to link to the main issue during experimentation in the private fork to avoid polluting the issue with references! StanFromIreland commented on Sep 16, 2026 Marking as a release-blocker to get Hugo's eyes on this. This seems pretty bad, and seems like a realistic scenario to hit in practice. Reacted by Bartosz Sławecki changed the title [-]lazy import a.b as c incorrectly binds a.b.b[/-] [+]`lazy import a.b as c` incorrectly binds to `a.b.b`[/+] on Sep 16, 2026grgalex commented on Sep 18, 2026 ContributorAuthor More actions Another bug found while investigating the present issue: #157757 hugovk commented on Sep 28, 2026 Fixed by #158092, removing release-blocker label. Keeping this issue open for now to decide if we want the test from #157626. Reacted by Stan Ulbrych and Marcelo Trylesinski
MetadataMetadata3.15bugs and security fixesbugs and security fixes3.16new features, bugs and security fixesnew features, bugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-lazy-importstype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error StatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions |