readthedocs / readthedocs/sphinx-autoapi
PEP695 generic type syntax interpretion as cross-reference
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 494
- Forks
- 147
- Avg merge
- 9m
- Merged PRs (30d)
- 1
Description
Hi,
since version 3.7.0 I detect a weird error in my documentation build. I have a function using the generic type syntax (overly simplified looking like):
def my_func[Args: ArgType](args: Args): ...
Now the sphinx build issues warnings like
my_file.rst:xx: WARNING: more than one target found for cross-reference 'Args': path.to.other_file.Args [ref.python]
with path.to.other_file.Args indeed being a class definition.
The actual build rst file generated from autoapi looks innocent (only part mentioning the function):
.. autoapisummary::
path.to.my_file.my_func
.. py:function:: my_func(args)
The line reported by Sphinx is not directly at one of the instances, but close after the autoapisummary.
I am using Python 3.12 and sphinx version 8.2.3.
My questions are:
- Is this expected behavior?
- Is it possible to support PEP695 also with names which could be used in independent modules?
- And is
autoapieven the root cause or is some other part of the documentation build responsible to fix the warning?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the Sphinx build with Python 3.12 and Sphinx 8.2.3 using the generated RST containing autoapisummary and py:function for my_func. Inspect the area around the reported line and determine whether AutoAPI or another documentation component interprets the PEP 695 names as cross-references. Done means the warning's responsible component and the support or workaround for these names are clearly established.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- documentation
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100