[Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)

[Mark Shannon]

Hi,

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 
language.

In fact, the addition of `__mro_entries__` makes `__class_getitem__` 
unnecessary.

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 
generic type.

For example, here is a minimal working implementation of `List`:

class Generic:
     def __init__(self, concrete):
         self.concrete = concrete
     def __getitem__(self, index):
         return self.concrete
     def __mro_entries__(self):
         return self.concrete

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 
respectively.
This rather suggests (to me at least) the name `__type__` instead of 
`__mro_entries__`

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.


Cheers,
Mark.