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

Mark Shannon mark at hotpy.org
Sun Nov 19 15:06:33 EST 2017

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.

More information about the Python-Dev mailing list