-
-
Notifications
You must be signed in to change notification settings - Fork 63
bug: when using import x.y.z as a, Griffe thinks a is an alias for x, not x.y.z #259
Copy link
Copy link
Closed
Labels
unconfirmedThis bug was not reproduced yetThis bug was not reproduced yet
Description
Description of the bug
When importing modules within a package and using an alias, Griffe incorrectly determines the target of that alias to be the top-level package, not the leaf module.
To Reproduce
$ cd /tmp/XYZ
$ export PYTHONPATH=/tmp/XYZ
$ echo "import urllib.parse as parse" > bug_demo1.py
$ griffe dump -LDEBUG bug_demo1
INFO Loading package bug_demo1
DEBUG Found bug_demo1: loading
DEBUG Loading path /tmp/XYZ/bug_demo1.py
INFO Finished loading packages
{
"bug_demo1": {
"kind": "module",
"name": "bug_demo1",
"labels": [],
"members": [
{
"kind": "alias",
"name": "parse",
"target_path": "urllib",
"lineno": 1,
"endlineno": 1
}
],
"filepath": "/tmp/XYZ/bug_demo1.py"
}
}Note here that the alias parse is resolving to urllib. It should resolve to urllib.parse instead.
$ echo "import xml.etree.ElementTree as ET" > bug_demo2.py
$ griffe dump -LDEBUG bug_demo2
INFO Loading package bug_demo2
DEBUG Found bug_demo2: loading
DEBUG Loading path /tmp/XYZ/bug_demo2.py
INFO Finished loading packages
{
"bug_demo2": {
"kind": "module",
"name": "bug_demo2",
"labels": [],
"members": [
{
"kind": "alias",
"name": "ET",
"target_path": "xml",
"lineno": 1,
"endlineno": 1
}
],
"filepath": "/tmp/XYZ/bug_demo2.py"
}
}Here too the alias ET is resolving to xml instead of to xml.etree.ElementTree.
Full traceback
(Included above.)
Expected behavior
The aliases should resolve correctly.
Environment information
$ griffe --debug-info
- __System__: Linux-######
- __Python__: cpython 3.11.###
- __Environment variables__:
- `PYTHONPATH`: `/tmp/XYZ`
- __Installed packages__:
- `griffe` v0.42.1(Griffe was installed from PyPI.)
Additional context
I originally encountered this issue while documenting (with mkdocs, mkdocstrings and mkdocs-autorefs) a module xxx.yyy.B that was importing xxx.yyy.A as A. mkdocstrings failed to resolve/expand references to A.SomeClass as xxx.yyy.A.SomeClass, and instead linked to the (non-existing) xxx.SomeClass instead.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
unconfirmedThis bug was not reproduced yetThis bug was not reproduced yet