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

[Guido van Rossum]

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 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
>
>
>
> _______________________________________________
> 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>