On Fri, Nov 10, 2017 at 8:33 PM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 10 November 2017 at 18:39, Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi <levkivskyi@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 +