Special-case value-expression inference of special form subscriptions #16877
+10
−3
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.
Summary
Currently for something like
X = typing.Tuple[str, str]
, we infer the value ofX
asobject
. That's becauseTuple
(like many of the symbols in the typing module) is annotated as a_SpecialForm
instance in typeshed's stubs:ruff/crates/red_knot_vendored/vendor/typeshed/stdlib/typing.pyi
Line 215 in 23382f5
and we don't understand implicit type aliases yet, and the stub for
_SpecialForm.__getitem__
says it always returnsobject
:ruff/crates/red_knot_vendored/vendor/typeshed/stdlib/typing.pyi
Lines 198 to 200 in 23382f5
We have existing false positives in our test suite due to this:
ruff/crates/red_knot_python_semantic/resources/mdtest/annotations/annotated.md
Lines 76 to 78 in 23382f5
and it's causing many new false positives in #16872, which tries to make our annotation-expression parsing stricter in some ways.
This PR therefore adds some small special casing for
KnownInstanceType
variants that fallback to_SpecialForm
, so that these false positives can be avoided.Test Plan
Existing mdtest altered.
Cc. @MatthewMckee4