[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
- Previous message (by thread): [Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)
- Next message (by thread): [Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 returnlist
then shouldissubclass(x, List)
act likeissubclass(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>
- Previous message (by thread): [Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)
- Next message (by thread): [Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]