Document variance change in subclasses #3179
Conversation
|
Summary of possible changes in variance (going down the inheritance hierarchy):
Edge case: |
There was a problem hiding this comment.
I think it is to early to make this PR. We first need an issue where this could be discussed. This is not controversial from the theoretical point of view, but quite controversial from practical point of view (e.g. Container should be covariant).
Also, I would first updated PEP 483 - "Theory of type hints" (it actually contains the example of going from covariant to contravariant with empty bodies). Also PEP 483 allows a more detailed discussion (it is important to show an example when this is not safe).
Only after PEP 483 is updated and actual checks are implemented in mypy, then we could add this to mypy docs.
docs/source/generics.rst
Outdated
|
|
||
| from typing import Generic, TypeVar, Tuple, Iterable | ||
|
|
||
| K = TypeVar('K') |
There was a problem hiding this comment.
It looks like this definition of type variable and the one below should be exchanged.
docs/source/generics.rst
Outdated
|
|
||
| from typing import Generic, TypeVar, Tuple, Iterable | ||
|
|
||
| K = TypeVar('K') |
There was a problem hiding this comment.
You want a covariant one here, probably.
docs/source/generics.rst
Outdated
|
|
||
| K_co = TypeVar('K_co', covariant=True) | ||
| class InvariantSet(Generic[K], CovariantSet[K]): | ||
| def __contains__(self, key: K) -> bool: ... |
There was a problem hiding this comment.
This is different from how __contains__ is defined for e.g. Container, the latter has key: object.
There was a problem hiding this comment.
Ah yes, interesting. At the same time, it uses type variable in Enum.Flag, stdlib/2/collections.pyi and lib-stub/typing.pyi
docs/source/generics.rst
Outdated
| class InvariantSet(Generic[K], CovariantSet[K]): | ||
| def __contains__(self, key: K) -> bool: ... | ||
|
|
||
| but this is not: |
There was a problem hiding this comment.
But mypy does not prohibit this currently.
There was a problem hiding this comment.
Hmm it will prohibit it, if there are any methods or attributes in the base class at all; mypy will complain that they don't allow contravariance.
There was a problem hiding this comment.
Currently it doesn't, and this is main reason why I think it is premature.
I just tried your new example (fixing key annotation in the subclass, it should be K_contra) and mypy doesn't complain.
|
Should this be closed until we've reached agreement on the feature??? |
|
Yes |
The intent is to clarify that it's ok to change variance of type variables in subclasses; this is useful if someone wants to separate the interface into the parts that are covariant and contravariant in a type variable (rather than living with the overly-pessimistic invariance and/or overruling the type checker).