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

Ivan Levkivskyi levkivskyi at gmail.com
Mon Nov 20 15:32:41 EST 2017


On 20 November 2017 at 10:22, Mark Shannon <mark at hotpy.org> wrote:

On 19/11/17 22:36, Ivan Levkivskyi wrote:

Except that there is no such thing as object.getitem. Probably you_ mean PyObjectGetItem (which is just what is done by BINARYSUBSCR opcode). In fact, I initially implemented type.getitem, but I didn't like it for various reasons. Could you elaborate?

I didn't like that although type.getitem would exist, it would almost always raise, which can be confusing. Also dir(type) is already long, I don't want to make it even longer. Maybe there were other reasons that I forgot.

Anyway, I propose to stop here, since this is not about the PEP, this is about implementation. This is a topic of a separate discussion.

Given the power and flexibility of the built-in data structures, defining custom containers is relatively rare. I'm not saying that it should not be considered,

but a few minor hurdles are acceptable to keep the rest of the language

(including more common uses of type-hints) clean.

This essentially means changing decisions already made in PEP 484 and not a topic of this PEP. Also,

@Generic[T]
class C:
    ...

is currently a syntax error (only names and function calls are allowed in a decorator). Finally, it is too late to change how generics are declared, since it will break existing code.

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 _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. Indeed, but you do mention issubclass in the PEP. I think a few extra words of explanation would be helpful.

OK, I will add a comment to the PEP.

-- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171120/86c542dc/attachment.html>



More information about the Python-Dev mailing list