2017-01-18 12:33 GMT+01:00 Antoine Pitrou <solipsis at pitrou.net>: > I don't think I thought about that idea at the time. tp_finalize > doesn't benefit many extension types, so it's not a huge burden to add > a FLAGS value for the few cases where you want to use it. It isn't obvious to me that I have to define explicitly a Py_TPFLAGS_HAVE_FINALIZE flag if I want to _inherit_ the finalizer from the base class. The flag requires an #ifdef to only define it on Python >= 3.4, which can be painful when you have to support older Python versions and want a single code base for all Python versions. If a C extension defines a type which inherit from a type which has a finalizer, currently the finalizer is not inherited if the new type doesn't set explicitly the Py_TPFLAGS_HAVE_FINALIZE flag. I checked the _socket.socket type. Hopefully, sock_dealloc() calls PyObject_CallFinalizerFromDealloc(), so I guess that it should "just work" if tp_finalize is not inherited in the tp_finalize slot. But for tp_fastcall, if a type doesn't have the Py_TPFLAGS_HAVE_FASTCALL flag, the fastcall_wrapper() has to find the first base class with a tp_fastcall slot which. The search has a complexity of O(n), so it has an impact on performance (even if the impact is low). The flag only says that the C structure contains the field, not that it's set. So I think that it's safe to add Py_TPFLAGS_HAVE_FINALIZE and Py_TPFLAGS_HAVE_FASTCALL to Py_TPFLAGS_DEFAULT. Victor
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4