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 kristjan.jonsson
Recipients Jim.Jewett, amaury.forgeotdarc, asvetlov, dstanek, kristjan.jonsson, loewis, pitrou, rhettinger, stutzbach, tim.peters
Date 2012-04-07.10:30:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333794624.75.0.565245447224.issue9141@psf.upfronthosting.co.za>
In-reply-to
Content
Jim: The edge case of collecting an object that is alone in a cycle is something that isn't handled.  I'm also not sure that it is worth doing or even safe or possible.  but that is beside the point and not the topic of this patch.

Martin: This patch is formalizing a known fact about cpython objects, albeit an uncommon one:  Some objects with finalizers can be safely collected if they are in a certain state.  The canonical example is the PyGeneratorObject.  gccollect.c has special code for this type and there is a special evil API exposed to deal with the case.

_This patch is not changing any behaviour._  Generator objects that are in a special state of existance cannot be collected.  Rather, they are (and always have been) put in gc.garbage along with the rest of their cycle chain.  In other cases, the finalizer causes no side effects and simply clearing them is ok.  I couldn't tell you what those generator execution states are, but the fact is that they exist.

A similar problem exists in Stackless python with tasklets.  We solved it in this generic way there rather than add more exceptional code to gcmodule.c and this patch is the result of that work.  In Stackless, the inverse is true:  An object without an explicit finalizer can still be unsafe to collect, because the tp_dealloc can do evil things, but doesn't always, depending on object state.

So, objects who change their mind about whether they can be collected or not are a fact of life in python.  Yes, even cPython.  This patch aims to formalize that fact and give it an interface, rather than to have special code for generator objects in gcmodule.c and an inscrutable API exposed (PyGen_NeedsFinalizing())

About reusing the slot:  Slots are a precious commodity in python.  This particular slot is undocumented and used only for one known thing:  To distinguish PyTypeObjects from PyHeapTypeObjects.  In fact, creating a slot and not using special case code (like they did for PyGeneratorObjects) was forward thinking, and I'm trying to build on that.  Renaming the slot is a fine idea.

A brief search on google code (and google at large) showed no one using this slot.  It is one of those undocumented strange slots that one just initializes to 0.
History
Date User Action Args
2012-04-07 10:30:24kristjan.jonssonsetrecipients: + kristjan.jonsson, tim.peters, loewis, rhettinger, amaury.forgeotdarc, pitrou, dstanek, stutzbach, asvetlov, Jim.Jewett
2012-04-07 10:30:24kristjan.jonssonsetmessageid: <1333794624.75.0.565245447224.issue9141@psf.upfronthosting.co.za>
2012-04-07 10:30:24kristjan.jonssonlinkissue9141 messages
2012-04-07 10:30:23kristjan.jonssoncreate