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

Guido van Rossum guido at python.org
Mon Nov 20 19:34:03 EST 2017

Mark, with that comment now added to the PEP, are you satisfied? https://github.com/python/peps/pull/479

On Mon, Nov 20, 2017 at 12:32 PM, Ivan Levkivskyi <levkivskyi at gmail.com> wrote:

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 _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. 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

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ guido%40python.org

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171120/7c7a8962/attachment.html>

More information about the Python-Dev mailing list