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 kristjan.jonsson, pitrou, tim.peters
Date 2010-07-04.15:24:38
SpamBayes Score 0.018271582
Marked as misclassified No
Message-id <1278257081.73.0.16668625991.issue9141@psf.upfronthosting.co.za>
In-reply-to
Content
I don't understand the tp_del / tp_dealloc argument here.  This is really not the concern of gc.  Gc only goes and finds unreachable objects, and if they are deemend collectable, makes them go away by clearing their references.
GC only cares that during the final release of any objects in a reference cycle, no non-trivial code may run (for various technical reasons).  So, objects deemed "sensitive" in this way, are left alone (and put in gc.garbage instead).
GC has no other knowledge of how objects behave, if or when any finalizers are called.  The only thing gc does is calling Py_DECREF (through the tp_clear slot).  Everything else is up to the objects.

The intent of this patch is for objects themselves to be able to provide better information to GC as to whether they are too "sensitive" to be cleared by GC, rather than GC relying solely on the presence of a __del__ method, or using the builtin special case knowledbe for PyGen objects.

Whether finalizers are called from tp_del or tp_dealloc is beyond the scope of the gc module or, indeed, this patch.
History
Date User Action Args
2010-07-04 15:24:42kristjan.jonssonsetrecipients: + kristjan.jonsson, tim.peters, pitrou
2010-07-04 15:24:41kristjan.jonssonsetmessageid: <1278257081.73.0.16668625991.issue9141@psf.upfronthosting.co.za>
2010-07-04 15:24:40kristjan.jonssonlinkissue9141 messages
2010-07-04 15:24:39kristjan.jonssoncreate