Skip to content

bug: when using import x.y.z as a, Griffe thinks a is an alias for x, not x.y.z #259

@the-13th-letter

Description

@the-13th-letter

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.

Metadata

Metadata

Assignees

Labels

unconfirmedThis bug was not reproduced yet

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions