-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
SubtypeVisitor: treat ParamSpec as if it was a covariant TypeVar #12096
Conversation
This comment has been minimized.
This comment has been minimized.
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.
Thank you! This looks much better than my solution 👍
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.
This is roughly what I did in #11847 but better -- I'd love to see this merged :D
Can you explain why we treat it as covariant and not invariant type variable? The semantic analyzer constructs param spec already with a variance attached (always INVARIANT because PEP doesn't specify what to do for other variances) |
In my case because I want mypy/test-data/unit/check-parameter-specification.test Lines 942 to 998 in 81994f1
This was because some counterexample though it's so long ago I don't remember exactly why nor if there was another way. And to be clear: TypeVarTuples specifies that they are invariant, I believe ParamSpecTypes don't have such a thing in the PEP (unless I'm misremembering, which is possible). |
If I change it to
I haven't figured out why " |
This comment has been minimized.
This comment has been minimized.
I'm not sure if we still need this. The tests pass without this PR. |
This comment has been minimized.
This comment has been minimized.
IMO yes. Why? Because this fixes my worse yet similar fix (which is why this is working now in master :P) in 272de9a |
How exactly is my fix better? What kind of code would fail the type check with your fix and pass with my fix, or vice versa? |
With TypeVarTuple, the variance is invariant but it falls under the |
As far as I can tell, mypy doesn't really support TypeVarTuple yet, so we can't test this PR properly. |
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
Thanks for the PR! A lot has changed here, but looks like core of this change is on master |
Description
Fixes #12033. The problem was that
Foo[<nothing>]
was not a subtype ofFoo[_P]
, where_P
is a paramspec. This caused a weird problem whereFoo[_P]
was not a subtype of itself, because it got rewritten asFoo[<nothing>]
being a subtype ofFoo[_P]
.I'm still not sure if this is correct, as this is my first PR that does something nontrivial.
Test Plan
Tests mostly copied from #12034 (an alternative PR to fix the same problem).