-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Fix type variable clash in nested positions and in attributes #14095
Changes from all commits
49d898d
8797003
c96dd45
eda5486
1a7fc22
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1654,7 +1654,7 @@ class C: | |
def bar(self) -> Self: ... | ||
foo: Callable[[S, Self], Tuple[Self, S]] | ||
|
||
reveal_type(C().foo) # N: Revealed type is "def [S] (S`-1, __main__.C) -> Tuple[__main__.C, S`-1]" | ||
reveal_type(C().foo) # N: Revealed type is "def [S] (S`1, __main__.C) -> Tuple[__main__.C, S`1]" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure if I remember the exact rules, but shouldn't S continue to use a negative ID, since it's a method-scoped typevar instead of a class-scoped one? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, but we didn't follow this convention since when we started using |
||
reveal_type(C().foo(42, C())) # N: Revealed type is "Tuple[__main__.C, builtins.int]" | ||
class This: ... | ||
[builtins fixtures/tuple.pyi] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is having this something we actually want to support? (Allowing "T" to exist as a "free" typevar)
I was always under the impression that having free typevars like this was effectively undefined behavior and not something we really want to encourage users to do.
So, an alternative approach here might be to report an error here then replace 'T' with either 'object', 'never', or 'any' for the purposes of subsequent type analysis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple things here:
Callable[[T], str]
are fine (e.g. for a function with unused argument), the opposite likeCallable[[str], T]
are wrong/undefined (and mypy actually gives an error for such types when defining a function).x: Callable[[T], Tuple[T, R]]
and adjust the callsite, I just use the simplest case for a test. I will update the test to make it more clear.