On 04/26/2013 01:57 PM, Chris Angelico wrote:
On Sat, Apr 27, 2013 at 3:42 AM, Dave Angel <da...@davea.name> wrote:
I don't see what your "special" temporary object actually accomplishes.
Seems to me you need to declare that your __del__() methods promise not to
reference each other, and the gc would then check all objects in the cycle,
and do its present behavior if any of the destructors is not specially
declared.
It wouldn't be declared; it'd simply throw an exception if anything
different happened.
I'm not sure how often you'd have a non-trivial destructor that wouldn't
reference any objects. And doing a static analysis of what will happen
during the destructor would be pretty messy. So the best I and come up with
is to keep the declaration, but require a try/catch to cleanly terminate
each destructor if it ever references anything in the tree.
And yeah. If you catch the exception inside __del__, you can cope with
the destructed object yourself (or LBLY, if you wish). Alternatively,
you just proceed as normal, and when your __del__ throws an exception,
the gc then copes (not sure *how* it should cope - log it to stderr
and carry on?). Same as normal exception handling.
The advantage of this style is that the code to deal with the cycle is
kept right in the cyclic object's destructor - right where the problem
is. Doing it through gc.garbage requires that some other operation
periodically check for garbage - after the GC has done its own
periodic check. Seems simpler/cleaner to do it as part of the gc run
itself.
You must think me dense by now. But I don't understand what the two
different garbage collection operations are that you're positing.
As far as I know, there's ref counting, which is quick, and frees
something as soon as the count goes to zero. Then there's gc, which has
to scan through all the objects from a known starting set, and identify
those things which aren't accessible, and free any that don't have a
__del__() method.
And it's only in the gc step that cycles and such are identifiable.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
