[Python-ideas] PEP 560 (second post)

[Koos Zevenhoven]

On Fri, Nov 10, 2017 at 8:33 PM, Ivan Levkivskyi <levkivskyi at gmail.com>
wrote:

> On 10 November 2017 at 18:39, Koos Zevenhoven <k7hoven at gmail.com> wrote:
>
>> On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi <levkivskyi at gmail.com>
>> wrote:
>>
>>> ​
>>>
>> ​
>>> After creating the class,
>>> the original bases are saved in ``__orig_bases__`` (currently this is
>>> also
>>> done by the metaclass).
>>>
>>>
>> ​Those are *still* bases, right, even if they are not in the mro?​ I'm
>> not sure if this is a naming thing or something even more.
>>
>
> The objects that have __subclass_base__ method (proposed to rename to
> __mro_entry__)
> are removed from __bases__ attributed of the newly created class.
> Otherwise they may cause a metaclass conflict.
> One can however still call them syntactic (or static?) bases. For example
> this is how it is going to be used by typing:
>
>     from typing import List
>
>     class Tokens(List[int]):
>         ...
>
>     assert Tokens.__bases__ == (list,)
>

​Why is List[int] not allowed to be the base? Neither method-lookup
performance nor the metaclass conflict issue seem to depend on whether
List[int] is in __bases__.



>
>
>> NOTE: These two method names are reserved for exclusive use by
>>> the ``typing`` module and the generic types machinery, and any other use
>>> is
>>> strongly discouraged.
>>>
>>
>> ​Given the situation, that may be a good thing. But will it really work?
>> I think it is also strongly discouraged to invent your own dunder method
>> names, but people still do it.​
>>
>
> Terry had a similar comment. I will "soften" this formulation in the next
> revision of the PEP.
>
>
​
Right, I assume you mean the one where he pointed out that implicitly
turning the methods into staticmethods based on their names makes those
names reserved words.
​
​-- Koos

-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171110/7b8cdea8/attachment-0001.html>