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 lehmannro
Recipients asvetlov, jimjjewett, kristjan.jonsson, lehmannro, pitrou, stutzbach
Date 2010-12-03.10:06:57
SpamBayes Score 1.9094442e-07
Marked as misclassified No
Message-id <1291370819.58.0.854729345829.issue10576@psf.upfronthosting.co.za>
In-reply-to
Content
A few issues I'd like to raise:

(1) Multiple callback chains.  Is there any code in your existing use case of GC callbacks where you don't check for the phase argument and follow different code paths depending on it?  If not, having two callback chains should be fine and takes the burden from the programmer to the implementors.  (This is feasible if we *only ever* have two values for the phase.)

(2) Single collections.  Currently, neither PyGC_Collect nor gc.collect() invoke the callbacks (since they do not call collect_generations).  Is this an oversight or intentional?

(3) Error checking.  What about callbacks which are bound to fail on each and every invocation, ie. because of wrong signatures.  Should these be flat-out rejected in some way *on registration*, automagically removed when first encountered, or are we okay with errors slammed into the user's face every so often because he should REALLY fix them?

(4) Interop.  Can this be supported as easily on other VMs?  (That's perhaps a good reason for the statistics to be a dict, for GCs providing vastly different amounts of information.)
History
Date User Action Args
2010-12-03 10:06:59lehmannrosetrecipients: + lehmannro, jimjjewett, pitrou, kristjan.jonsson, stutzbach, asvetlov
2010-12-03 10:06:59lehmannrosetmessageid: <1291370819.58.0.854729345829.issue10576@psf.upfronthosting.co.za>
2010-12-03 10:06:58lehmannrolinkissue10576 messages
2010-12-03 10:06:58lehmannrocreate