-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Invariance not enforced for class-scoped TypeVar used in base class expression #13713
Comments
It's gotten late for me, so I'm now confused by variance. @erictraut I noticed you didn't implement the check for whether a covariant class derives from a contravariant class, and vice versa? I think we should do that as well, because it breaks transitivity of subtyping.
I think both mypy and pyright agree that It looks like typeshed breaks this with Container and SupportsGetItem (in the following example pyright gives something different because pyright narrows as per #2008 (comment) , but you could trick it into showing the same behaviour)...
|
Isn't this a duplicate of a (super-old) #736? |
@hauntsaninja, yes, I agree that mismatched covariance/contravariance mismatch is also a problem. I think it's unlikely that anyone would attempt to use those combinations, but for completeness that check could be added. [Update: I modified pyright to include this check as well.] [Update 2: After claiming that this would be unlikely to happen, I see that typeshed violates this in one place — in the @ilevkivskyi, yes, this looks like a duplicate. Apologies, I didn't notice the existing bug. I'll close this one accordingly. |
Mypy does not detect the case where a covariant or contravariant class (i.e. a class that is parameterized by a class-scoped covariant or contravariant TypeVar) derives from an invariant class. This creates a type correctness hole as shown in the following code sample.
Pyright likewise did not previously catch this case. I just added the check here.
The text was updated successfully, but these errors were encountered: