[Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

[Serhiy Storchaka]

15.12.17 04:00, Guido van Rossum пише:
> In the light of Antoine's and Stephan's feedback I think this can be 
> reconsidered -- while I want to take a cautious stance about resource 
> consumption I don't want to stand in the way of progress.

I don't see any problems with implementing this on types defined in C. 
This isn't harder than implementing __sizeof__ or pickling support, and 
NumPy classes already have implemented both. Maybe Yury forgot about 
METH_STATIC and METH_CLASS?

The cost of adding new slots:

1. Increased memory consumption. This increases the size of *every* 
class, even if they don't implement this feature.

2. Increased class initialization time. For every class for every slot 
we need to look up corresponding methods in dictionaries of the class 
itself and all its parents (caching doesn't work fine at this stage). 
Significant part of class initialization time is spent on initializing 
slots. This will increase the startup time and the time of creating 
local classes. The relative overhead is more significant in Cython.

3. We need to add a new type feature flag Py_TPFLAGS_HAVE_*. The number 
of possible flags is limited, and most bits already are used. We can add 
the limited number of new slots, and should not spent this resource 
without large need.

4. Increased complexity. Currently the code related to PEP 560 is 
located in few places. With supporting new slots we will need to touch 
more delicate code not related directly to PEP 560. It is hard to review 
and to test such kind of changes. I can't guarantee the correctness.

Some libraries can create new classes on demand (see for example 
https://rhye.org/post/python-cassandra-namedtuple-performance/ and not 
accepted proposition in https://bugs.python.org/issue13299). This 
increases the cost of items 1 and 2.