Repository navigation
parser(python): imports of a module with a .pyi beside it resolve to the .py - #1878
Merged
swapnilpaliwal-sd merged 1 commit intoOct 10, 2026
Conversation
…it resolves to the .py The project linker keys modules by qualified name, and a package that ships `impl.pyi` beside `impl.py` declares that name twice. The later file won the map, and `.pyi` sorts after `.py`, so `from .impl import *` and `import pkg` resolved to the stub. The engine refuses a stub declaration as an edge target, so every call into such a package ended at the library boundary and its tests reached nothing in it. A stub no longer replaces a non-stub module of the same name. A stub with no `.py` beside it is still the import's target. Co-authored-by: axiomcode-bot[bot] <334110751+axiomcode-bot[bot]@users.noreply.github.com>
This was referenced Oct 9, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom. In a Python package that ships
.pyistubs beside its.pymodules,impact/--testson a function in the package returned no tests: every call into the package ended at the library boundary.Cause. The parser's project linker keys modules by qualified name.
impl.pyandimpl.pyishare one, the later file wins, and.pyisorts after.py, so imports resolved to the stub. The engine correctly never makes a stub declaration an edge target.Fix. A stub does not replace a non-stub module of the same name; a stub-only module is still resolved. Parser package stays 0.2.0.
Evidence (16 public Python repositories, mutation oracle, base = current integration branch):
Two repositories ship stubs this way: recall 0.015 → 0.985 and 0.512 → 0.604 (precision 0.629 → 0.582 on the second, source-caller recall 0.610 → 0.636). The other 14 are unchanged on every metric. Parser Python suite 23/23; query cases python 308/308; Python engine suite 43/43, torture unchanged. New case
stub-beside-source-resolves-to-sourcefails on the base parser and passes here, with a control that the stub is never an edge target.