On 20 November 2017 at 10:22, Mark Shannon <m...@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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
