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.