Martin v. Löwis <mar...@v.loewis.de> added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9141> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
