Home Original page

[Python-Dev] Can we use "designated initializer" widely in core modules?

Victor Stinner victor.stinner at gmail.com
Wed Jan 18 02:44:29 EST 2017 
2017-01-18 3:28 GMT+01:00 Guido van Rossum <guido at python.org>:
> I recommend being reluctant to add new fields -- the number of type objects
> is larger than you'd think and these are static bytes which I consider a
> relatively expensive resource.
>
> There's also an ABI issue with new fields -- new fields can only be accessed
> after checking that the type object has been compiled with a version of the
> headers that defines the field, else you'd be accessing garbage bytes.

A new t_finalize field was added to the PyTypeObject object:
https://www.python.org/dev/peps/pep-0442/

The ABI is protected by a new Py_TPFLAGS_HAVE_FINALIZE flag in
tp_flags. If a type doesn't have this flag, the tp_finalize is not
read nor written. If an extension was compiled for Pyhon 3.3, static
PyTypeObject types are smaller than Python 3.4 types, since the
compiler used Python 3.3 size without tp_finalize.

I'm working on adding a new tp_fastcall field with a new
Py_TPFLAGS_HAVE_FASTCALL flag. Same story, tp_fastcall is only used if
Py_TPFLAGS_HAVE_FASTCALL is set. A wrapper is used to call the
tp_fastcall field of base classes if needed:
http://bugs.python.org/issue29259

My patch adds Py_TPFLAGS_HAVE_FINALIZE and Py_TPFLAGS_HAVE_FASTCALL to
Py_TPFLAGS_DEFAULT. So all modules compiled with Python 3.7 will
announce that they have tp_finalize and tp_fastcall fields, even if
they are NULL. I don't know why this change wasn't done before for
tp_finalize. Having Py_TPFLAGS_HAVE_FINALIZE/FASTCALL allows to
inherit tp_finalize/fastcall in child classes.

I want to add tp_fastcall for performance, to avoid the creation of
temporary tupe/dict to pass arguments. I measured a speedup up of 22%
on the bm_telco benchmark.

Victor
More information about the Python-Dev mailing list