-
-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WARNING: Cannot resolve forward reference in type annotations of "<MyMethod>": name '<NamedTuple>' is not defined #186
Comments
How would sphinx-autodoc-typehints know that its a member of the A class? This information cannot be derived from |
Well, I would expect So based on the behavior of the code, I would suggest that the class should be part of the namespace that is explored (i.e., nested classes are also added) while looking up what the type hint should refer to. I have less experience with sphinx so I could not point to an exact line in the implementation. But just try it out what happens if you comment out |
All these other tools use static analysis to get information. If you can point out how sphinx-autodoc-typehints could find this information, I could try and make a fix. |
Thank you very much. I will have a look whether I come across some solution. |
A PR for this would we welcome. |
I'm running into this with a custom class as well in my documentation. Is there an easy way of silencing this particular warning until a proper fix is made? |
I just did an experiment, and this works: class A:
class MyTuple(NamedTuple):
b: float
c: float Not only is this much neater than the alternative, it also makes |
It seems my case is a bit different, as I was running into issues with classes that used class MyClass:
_parameters : dict[str, ParametersClass] = {}
_attributes: list[dict[str, typing.Any]] = None The errors I was getting were resolved by turning these instances into strings: class MyClass:
_parameters : dict[str, "ParametersClass"] = {}
_attributes: list[dict[str, "typing.Any"]] = None I guess this is more of a workaround than an actual fix. (Confirmed working). |
Same issue happens during documentation generation for any from uuid import uuid4
from pydantic import BaseModel, PrivateAttr
class SampleModel(BaseModel):
_private: str = PrivateAttr(default_factory=lambda: str(uuid4()))
"""
Private field docstring.
""" |
I have a recursive types representing JSON serialisable mappings or sequences with a few more types: JSONPrimitive = None | bool | float | int | str
"""Represents JSON serialisable non-complex types."""
LogJSONPrimitive = JSONPrimitive | date | datetime | UUID4 | Decimal
"""
Represents JSON serialisable non-complex types but also allows :py:class:`date`, :py:class:`datetime`, :py:class:`Decimal`, and :py:class:`UUID4`.
"""
LogJSONSerializableSequence = Sequence[
'LogJSONPrimitive | LogJSONSerializableMapping | LogJSONSerializableSequence']
"""Represents a JSON serialisable sequence."""
LogJSONSerializableMapping = Mapping[
str, 'LogJSONPrimitive | LogJSONSerializableMapping | LogJSONSerializableSequence']
"""Represents a JSON serialisable mapping.""" Wherever I try to use
My extensions: extensions = [
'sphinx.ext.autodoc',
'sphinx.ext.napoleon',
'sphinx_autodoc_typehints',
'sphinx_immaterial',
'sphinx_datatables',
'sphinx.ext.intersphinx',
'sphinxcontrib.jquery',
] |
Describe the bug
I have some nested NamedTuple definitions and
sphinx_autodoc_typehints
cannot resolve them. Withoutsphinx_autodoc_typehints
, Sphinx has no issues generating a suitable documentation. In addition, PyCharm with its code linter is happy with it as well.To Reproduce
The Python file:
A default Sphinx configuration will just do the work . These are the loaded extensions:
Expected behavior
sphinx_autodoc_typehints
can resolve the typehint even though it is a nested NamedTuple and displays the NamedTuple as a member of the classA
.The text was updated successfully, but these errors were encountered: