2017-01-18 3:28 GMT+01:00 Guido van Rossum <gu...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
