[Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)
mark at hotpy.org
Sun Nov 19 15:06:33 EST 2017
I am very concerned by this PEP.
By far and away the largest change in PEP 560 is the change to the
behaviour of object.__getitem__. This is not mentioned in the PEP at
all, but is explicit in the draft implementation.
The implementation could implement `type.__getitem__` instead of
changing `object.__getitem__`, but that is still a major change to the
In fact, the addition of `__mro_entries__` makes `__class_getitem__`
The addition of `__mro_entries__` allows instances of classes that do
not subclass `type` to act as classes in some circumstances.
That means that any class can implement `__getitem__` to provide a
For example, here is a minimal working implementation of `List`:
def __init__(self, concrete):
self.concrete = concrete
def __getitem__(self, index):
List = Generic(list)
class MyList(List): pass # Works perfectly
class MyIntList(List[int]): pass # Also works.
The name `__mro_entries__` suggests that this method is solely related
method resolution order, but it is really about providing an instance of
`type` where one is expected. This is analogous to `__int__`,
`__float__` and `__index__` which provide an int, float and int
This rather suggests (to me at least) the name `__type__` instead of
Also, why return a tuple of classes, not just a single class? The PEP
should include the justification for this decision.
Should `isinstance` and `issubclass` call `__mro_entries__` before
raising an error if the second argument is not a class?
In other words, if `List` implements `__mro_entries__` to return `list`
then should `issubclass(x, List)` act like `issubclass(x, list)`?
(IMO, it shouldn't) The reasoning behind this decision should be made
explicit in the PEP.
More information about the Python-Dev