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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
