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-05.20:56:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333659420.64.0.561343212689.issue9141@psf.upfronthosting.co.za>
In-reply-to
Content
I think the second patch is a fairly straightforward enhancement to the existing situation.  It still feels a bit like an awkward half-measure, though.

(1)  If a class does have a finalizer, instances should still be able to say "Go ahead and collect me, I don't happen to be in the problematic state."  (In other words, there should be a return value that means not to bother checking for the existence of a tp_del / __del__ method.)

(2)  It should be explicit whether or not this is:
  (2a) just an inquiry ("If you were in a cycle, could I collect you?),
  (2b) a statement plus inquiry ("You are in a cycle.  Can I collect you?"), or
  (2c) a request ("You are in a cycle, and I would like to collect you.  Clean up if you can, then tell me whether you are still uncollectable.")

(3)  It may be worth adding an additional slot for safe idempotent finalizers.  (Earlier suggestions called this __close__, but I suppose __finalize__ might be more general.)  Once a garbage cycle is detected, go ahead and call that slot's method before giving up and sticking the whole thing in garbage.  If python classes could also fill this slot, it would look a lot like (2c).
History
Date User Action Args
2012-04-05 20:57:00Jim.Jewettsetrecipients: + Jim.Jewett, tim.peters, loewis, rhettinger, amaury.forgeotdarc, pitrou, kristjan.jonsson, dstanek, stutzbach, asvetlov
2012-04-05 20:57:00Jim.Jewettsetmessageid: <1333659420.64.0.561343212689.issue9141@psf.upfronthosting.co.za>
2012-04-05 20:57:00Jim.Jewettlinkissue9141 messages
2012-04-05 20:56:59Jim.Jewettcreate