On 19 November 2017 at 21:06, Mark Shannon <m...@hotpy.org> wrote:
> 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.
>
Except that there is no such thing as object._getitem__. Probably you mean
PyObject_GetItem (which is just what is done by BINARY_SUBSCR opcode).
In fact, I initially implemented type.__getitem__, but I didn't like it for
various reasons.
I don't think that any of the above are changes to the language. These are
rather implementation details. The only unusual thing is that while dunders
are
searched on class, __class_getitem__ is searched on the object (class
object in this case) itself. But this is clearly explained in the PEP.
> In fact, the addition of `__mro_entries__` makes `__class_getitem__`
> unnecessary.
>
But how would you implement this:
class C(Generic[T]):
...
C[int] # This should work
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__`
>
This was already discussed during months, and in particular the name
__type__ was not liked by ... you
https://github.com/python/typing/issues/432#issuecomment-304070379
So I would propose to stop bikesheding this (also Guido seems to like the
currently proposed name).
> 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.
>
I think this is orthogonal to the PEP. There are many situations where a
class is expected,
and IMO it is clear that all that are not mentioned in the PEP stay
unchanged.
--
Ivan
_______________________________________________
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
