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

[Ivan Levkivskyi]

On 19 November 2017 at 21:06, Mark Shannon <mark at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171119/f541fe1e/attachment.html>