Author loewis
Recipients Jim.Jewett, amaury.forgeotdarc, asvetlov, dstanek, kristjan.jonsson, loewis, pitrou, rhettinger, stutzbach, tim.peters
Date 2012-04-07.08:50:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333788622.69.0.482774941982.issue9141@psf.upfronthosting.co.za>
In-reply-to
Content
I'm still unclear about the rationale for this change. krisvale says in the patch and in msg109099 that this is to determine whether an object can be collected "at this time". Is the intended usage that the result value may change over the lifetime of the object?

If so, I'm -1 on the patch. If an object cannot be collected "at this time", it means that it is added to gc.garbage, which in turn means that it will never be collected (unless somebody explicitly clears gc.garbage).

Supporting the case of objects that can be collected despite living in a cycle is fine to me, but those objects must not change their mind.

Supporting the case of objects that are not collectable now, but may be collectable later, may have its use case (which one?), but this is not addressed by the patch (AFAICT). To support it, processing of the entire cycle must be postponed (to the next collection? to the next generation?).

I'm -0 on recycling the is_gc slot. Having a GC header and having a non-trivial tp_del are two unrelated issues. If this is done, I think it would be best to rename the slot to tp_gc_flags or something. There is also the slight risk of some type in the wild returning non-1 currently, which then would get misinterpreted.
History
Date User Action Args
2012-04-07 08:50:22loewissetrecipients: + loewis, tim.peters, rhettinger, amaury.forgeotdarc, pitrou, kristjan.jonsson, dstanek, stutzbach, asvetlov, Jim.Jewett
2012-04-07 08:50:22loewissetmessageid: <1333788622.69.0.482774941982.issue9141@psf.upfronthosting.co.za>
2012-04-07 08:50:22loewislinkissue9141 messages
2012-04-07 08:50:21loewiscreate