Skip to content

Fix ObjectNode.module_path#419

Merged
pawamoy merged 2 commits intomkdocstrings:mainfrom
mnesarco:main
Oct 10, 2025
Merged

Fix ObjectNode.module_path#419
pawamoy merged 2 commits intomkdocstrings:mainfrom
mnesarco:main

Conversation

@mnesarco
Copy link
Contributor

@mnesarco mnesarco commented Oct 8, 2025

For reviewers

  • I did not use AI
  • I used AI and thorougly reviewed every code/docs change

Description of the change

module_path property returns ModuleType in some scenarios where self.obj.__module__ has a ModuleType value, this causes bugs because other functions assume it returns a string with the name of the module.

It is not clear to me why self.obj.__module__ is ModuleType sometimes and str other times.

  File ".../.venv/lib/python3.11/site-packages/griffe/_internal/agents/nodes/runtime.py", line 38, in _same_components
    return [cpn.lstrip("_") for cpn in a.split(".")] == [cpn.lstrip("_") for cpn in b.split(".")]

AttributeError: module 'PathApp' has no attribute 'split'

@pawamoy
Copy link
Member

pawamoy commented Oct 9, 2025

Thanks for the report @mnesarco 🙂

Would it be possible for you to share the code that triggered this error? Or the project Git URL directly? I'd like to know why the __module__ attribute is an actual module instance and not just a string.

@pawamoy pawamoy mentioned this pull request Oct 9, 2025
Closed
@pawamoy
Copy link
Member

pawamoy commented Oct 9, 2025

From what I found, it seems that __module__ is only supposed to be a string, or None. But the docs might be unclear on that (reported in python/cpython#139842).

@pawamoy
Copy link
Member

pawamoy commented Oct 9, 2025 •
edited
Loading

Anyway, in practice if some dynamically built objects have their __module__ attribute to something else, we should handle that and not crash, so I will likely accept this change 🙂 Could be useful to add a DEBUG log when it's not a string!

@mnesarco
Copy link
Contributor Author

mnesarco commented Oct 9, 2025

@pawamoy
I am working on a project to generate python stubs from c++ bindings, so some modules are "builtin" and others are pure python. There is no public repo yet.

What I do is basically: loader.load("ModuleX") where ModuleX is provided by some c++ library or a normal python module. So I don't know the details of __module__ managed by those external libs.

@pawamoy
Copy link
Member

pawamoy commented Oct 9, 2025

I see, thanks, that's what I wanted to know. I suppose some of these compiled objects are mistakenly given a module instance as __module__ value instead of a string. If you can, try to report this issue to the maintainers of the C++ bindings you're working with. In any case we'll merge your fix to handle it in Griffe 🙂

@pawamoy
Copy link
Member

pawamoy commented Oct 9, 2025

WDYT of these log messages?

@mnesarco
Copy link
Contributor Author

mnesarco commented Oct 9, 2025

WDYT of these log messages?

Excellent! thank you.

@pawamoy pawamoy merged commit 06c2f2f into mkdocstrings:main Oct 10, 2025
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@mnesarco @pawamoy