This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients scoder, vstinner
Date 2020-06-17.07:24:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1592378644.34.0.752904690194.issue40989@roundup.psfhosted.org>
In-reply-to
Content
I looked into the freelists a bit more and (as always) it's not quite that simple. Calling _Py_NewReference() allows keeping the "ob_type" pointer in place, whereas PyObject_INIT() requires a blank object in order to set the type and properly ref-count heap types.

I think what that means is that there are at least two different cases for freelists: those that only keep the bare object memory alive (and can also support subtypes of the same size), and those that keep the (cleared) object alive, including its type. For the first, PyObject_INIT() works. For the latter, _Py_NewReference() seems the right helper function.

The advantage of keeping the object as it is is the much simpler freelist code in tp_dealloc(). All it needs to do is 1) clear the ref-counted object fields (if any) and 2) put it in the freelist. No other C-API interaction is needed. If we only want to keep the object memory, then we need C-API support in both tp_new() and tp_dealloc().

If _Py_NewReference() is removed/hidden, then it would be nice if there was a replacement for the use case of initialising an object from a freelist that already knows its type.
History
Date User Action Args
2020-06-17 07:24:04scodersetrecipients: + scoder, vstinner
2020-06-17 07:24:04scodersetmessageid: <1592378644.34.0.752904690194.issue40989@roundup.psfhosted.org>
2020-06-17 07:24:04scoderlinkissue40989 messages
2020-06-17 07:24:04scodercreate