![](https://secure.gravatar.com/avatar/d6b9415353e04ffa6de5a8f3aaea0553.jpg?s=120&d=mm&r=g)
On 9/27/2017 5:28 AM, Ivan Levkivskyi wrote:
Abstract ========
Initially PEP 484 was designed in such way that it would not introduce *any* changes to the core CPython interpreter. Now type hints and the ``typing`` module are extensively used by the community, e.g. PEP 526 and PEP 557 extend the usage of type hints, and the backport of ``typing`` on PyPI has 1M downloads/month. Therefore, this restriction can be removed.
It seem sensible to me that you waited awhile to discover what would be needed.
It is proposed to add two special methods ``__class_getitem__`` and ``__subclass_base__`` to the core CPython for better support of generic types.
I would not be concerned about anyone (mis)using reserved words. If the new methods were for general use, I would question making them automatically class methods. Having __new__ automatically being a static method is convenient, but occasionally throws people off. But if they were only used for typing, perhaps it is ok. On the other hand, I expect that others will use __class_getitem__ for the same purpose -- to avoid defining a metaclass just to make class[something] work. So I question defining that as 'typing only'. Without rereading the PEP, the use case for __subclass_base__ is not clear to me. So I don't know if there are other uses for it. -- Terry Jan Reedy