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

[Ivan Levkivskyi]

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 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.
>
>
> 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 `__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.
>>
>
> 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>