Repository navigation
intersphinx: fall back to py:data / py:attribute for py:class references - #14730
Open
bhaskargurram-ai wants to merge 1 commit into
Open
bhaskargurram-ai wants to merge 1 commit into
bhaskargurram-ai wants to merge 1 commit into
Conversation
Type aliases and type variables are documented as py:data or py:attribute, but references generated from annotations use the py:class role. The Python domain already falls back from 'class' to 'data' and then 'attr' when resolving such references locally, but intersphinx only searched the object types of the 'class' role. Apply the same ordered fallback when resolving a py:class reference against an inventory, without the legacy py:method alias that the 'attr' role adds for old property entries.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Type annotations can generate
py:classreferences for TypeVars and type aliases, even when other projects document them aspy:dataorpy:attribute. Intersphinx cannot resolve these references when the expectedpy:classtarget does not exist, which results in "reference target not found" warnings. Projects such as SymPy, BayBE and khisto-python have added workarounds for this.Sphinx 9.0 already addressed this for local references in #13808, by falling back from
py:classtopy:dataand thenpy:attribute. Intersphinx does not use the same fallback yet.This PR updates intersphinx to try
py:dataand thenpy:attributewhen apy:classlookup fails.What doesn't change:
Tests: a regression test that fails without the change and passes with it; the existing intersphinx and domain tests continue to pass.
Also adds an entry to CHANGES.rst and my name to AUTHORS.rst.
References
AI Disclosure
I used Claude Code to search for existing work, draft the code change in
sphinx/ext/intersphinx/_resolve.py.