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 Jim.Jewett
Recipients Jim.Jewett, amaury.forgeotdarc, asvetlov, dstanek, kristjan.jonsson, loewis, pitrou, rhettinger, stutzbach, tim.peters
Date 2012-04-06.19:51:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333741911.38.0.76066357888.issue9141@psf.upfronthosting.co.za>
In-reply-to
Content
> I don't think 2 is important.  Does the context of the call matter?
> It is merely a question of whether a finalizer will or will not do
> something trivial.

It would affect how I would write such functions.  If I knew that it wouldn't be called until the object was already garbage, then I be inclined to move parts of tp_del there, and break the cycle.

> Finalizers implemented in python can never run from garbage 
> collection.  the potential to do harm is simply too great.

__del__ methods do run, even if an object was collected by the cycle detector.  And they can't do any harm that couldn't also be done by a C finalizer.

The only change from today's situation with __del__ is that once an object is known to be cyclic garbage, it would get a chance to break the cycles itself (or, admittedly, to rescue itself) before the cycle-breaker began making arbitrary decisions or gave up and stuffed it in the uncollectable list.

Even in your case, instead of setting a timer to clean out garbage, you could have the garbage itself notify your cleaner that it needed attention.
History
Date User Action Args
2012-04-06 19:51:51Jim.Jewettsetrecipients: + Jim.Jewett, tim.peters, loewis, rhettinger, amaury.forgeotdarc, pitrou, kristjan.jonsson, dstanek, stutzbach, asvetlov
2012-04-06 19:51:51Jim.Jewettsetmessageid: <1333741911.38.0.76066357888.issue9141@psf.upfronthosting.co.za>
2012-04-06 19:51:50Jim.Jewettlinkissue9141 messages
2012-04-06 19:51:50Jim.Jewettcreate