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

Antoine Pitrou solipsis at pitrou.net
Fri Dec 15 11:36:30 EST 2017


On Fri, 15 Dec 2017 14:05:46 +0200
Serhiy Storchaka <storchaka at gmail.com> wrote:
> 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.

These are all very good points (except #1 which I think is a red
herring, see my posted example).  Do you have any general idea how to
speed up class creation?

Regards

Antoine.




More information about the Python-Dev mailing list