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

Ivan Levkivskyi levkivskyi at gmail.com
Sun Nov 19 17:36:51 EST 2017

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 _mroentries_ makes _classgetitem_ 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 _mroentries_

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 _mroentries_ before raising an error if the second argument is not a class? In other words, if List implements _mroentries_ 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>

More information about the Python-Dev mailing list