You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use dummy concrete type instead of Any when checking protocol variance (#20110)
Fixes#20108.
Variance checks for protocols follow a procedure roughly equivalent to
that described in [typing.python.org - Variance
Inference](https://typing.python.org/en/latest/spec/generics.html#variance-inference).
A major difference in mypy's current implementation is in Step 3:
> Create two specialized versions of the class. We’ll refer to these as
`upper` and `lower` specializations. In both of these specializations,
replace all type parameters other than the one being inferred by a dummy
type instance (a concrete anonymous class that is assumed to meet the
bounds or constraints of the type parameter).
Mypy currently uses `Any` rather than a concrete dummy type. This causes
issues during overload subtype checks in the example reported in the
original issue, as the specialisations when checking variance
suitability of `_T2_contra` look like:
```python
from typing import TypeVar, Protocol, overload
_T1_contra = TypeVar("_T1_contra", contravariant=True)
_T2_contra = TypeVar("_T2_contra", contravariant=True)
class A(Protocol[<_T1_contra=Any>, _T2_contra]):
@overload
def method(self, a: <_T1_contra=Any>) -> None: ...
@overload
def method(self, a: _T2_contra) -> None: ...
```
This PR replaces the use of `Any` with a dummy concrete type in the
entire protocol variance check to more closely follow the variance
inference algorithm in the spec and fixes this overload issue.
0 commit comments