Make Mapping covariant in keys (too).

[gvanrossum]

See python/typeshed#510

[ilevkivskyi]

@gvanrossum
I am not sure that I am comfortable with this. For example consider this code:

def fun(m: Mapping[float, Any]):
    return m[0.1]

class StrangeMap(Mapping[int, Any]):
    def __getitem__(self, item):
        return item << 5

fun(StrangeMap())

If Mapping would be covariant this will typecheck, since int is a subtype of float, therefore StrangeMap is a subtype of Mapping[float, Any]. But this code will raise TypeError at runtume.

Of course this example is a bit artificial, but I think there are realistic examples just going the same way.

[gvanrossum]

@JukkaL What do you think?

On Wed, Aug 31, 2016 at 11:56 AM, Ivan Levkivskyi notifications@github.com
wrote:

@gvanrossum https://github.com/gvanrossum
I am not sure that I am comfortable with this. For example consider this
code:

def fun(m: Mapping[float, Any]):
return m[0.1]
class StrangeMap(Mapping[int, Any]):
def getitem(self, item):
return item << 5

fun(StrangeMap())

If Mapping would be covariant this will typecheck, since int is a subtype
of float, therefore StrangeMap is a subtype of Mapping[float, Any]. But
this code will raise TypeError at runtume.

Of course this example is a bit artificial, but I think there are
realistic examples just going the same way.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#273 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACwrMurtnwGQvnWtuWVYkyQccwQhQOq8ks5qlc5EgaJpZM4JxET9
.

--Guido van Rossum (python.org/~guido)

[JukkaL]

As discussed in python/typeshed#510, this is clearly unsafe, but maybe the cases where the unsafety might manifest itself are more common that I originally thought :-(

Making it covariant in the value type should be less of a problem. We could use a separate type variable _T for the second argument of get and return Union[_T, _VT], but mypy might not be happy about this definition yet.

[gvanrossum]

OK, I'll close this for now, leaving Mapping covariant in the value but not in the type. (Alas, mypy doesn't understand that union yet, so get() still requires # type: ignore.)

[Prometheus3375]

If Mapping would be covariant this will typecheck, since int is a subtype of float

int is not a subtype of float at least in Python 3.9.1.

>>> issubclass(int, float)
False
>>> isinstance(1, float)
False

[gvanrossum]

int is not a subtype of float at least in Python 3.9.1.

But it is in for static type checkers, and this is specified by PEP 484.

[rhshadrach]

Is the only issue making Mapping covariant in the key with int/float? For example, I expect Mapping[A, C] to be compatible with Mapping[Union[A, B], C]. Looking at other issues, one other reason I've seen for not making Mapping covariant in the key is that a subclass can be mutable when the superclass is not. This seems to me to fall under "We're all adults here".

Tangential question - is the covariance/contravariance specified by a PEP? I couldn't find anything other than PEP 484 which says:

The read-only collection classes in typing are all declared covariant in their type variable (e.g. Mapping and Sequence). The mutable collection classes (e.g. MutableMapping and MutableSequence) are declared invariant. The one example of a contravariant type is the Generator type, which is contravariant in the send() argument type (see below).

which seems to indicate Mapping should be covariant in the key (but is slightly ambiguous, I suppose).

If I've captured the objections to making Mapping covariant in the key, then my take is that not making Mapping covariant in the key is foregoing a generally useful feature in good code for oddities some might experience in not-so-good code. But I suspect I may be missing some cases.

[ktbarrett]

Whole-type variance is not fine-grained enough to describe the relation here. Indexing is actually contravariant, setting is covariant as are other operations. The variance of the type, as it appears on a function, depends entirely on how the object is used. This is also related to python/typeshed#7121 and python/typeshed#7015 where methods are contravariant, but the type is covariant.

There is no way to describe this with Python's type system, as it stands.