Duncan Booth wrote: > Surely if you have a cycle what you want to do is to pick just *one* of the > objects in the cycle and break the link which makes it participate in the > cycle.
No, I really meant to do them all. I was trying to avoid creating an attractive nuisance. In http://mail.python.org/pipermail/python-dev/2006-March/063239.html, Thomas Wouters categorized the purpose of __del__ methods as [paraphrased] (A) Resource Cleanup (cycles irrelevant) (B) Object created a cycle, and knows how to break it safely. (C) Those which do things the style guide warns against. The catch is that objects in the first two categories have no way to know when they should do the cleanup, except by creating a __del__ method (as generators now do). For category (A), their __del__ methods should be called as early as possible. Even for category (B), it does no harm. Why waste time recalculating cycles more often than required? If the object is lying about whether it can be used to safely break cycles, that is a bug, and I would rather catch it as early as possible, instead of letting it hide behind "oh well, the cycle was already broken". In fairness, I had not fully considered category(C), when an object intends not only to revive itself, but to prevent its subobjects from cleaning up either. Nick Coghlan > A simple Boolean attribute (e.g. __finalized__) should be enough. ... > If it's both present and true, the GC can ignore the finaliser on that > instance That doesn't really take care of resource release, which needs to be called, and called early.(And the name will sound odd if it holds resources only sometimes, so that it has to flip the __finalized__ attribute.) -jJ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
