On 9/22/06, Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote: > I still think a rather nice solution would be to guarantee to call > __del__ (or __close__ or whatever) only once, as was discussed earlier:
How does this help? It doesn't say how to resolve cycles. This cycle problem is the cause of much implementation complexity and most user frustration (because the method doesn't get called). Once-only does prevent objects from usefully reviving them*selves*, but it doesn't prevent them from creating a revived copy. Since you still have to start at the top of a tree, they can even reuse otherwise-dead subobjects -- which keeps most of the rest of the complexity. And to be honest, I'm not sure you *can* remove the complexity, so much as you can move it. Enforcing no-revival-even-of-subobjects is the same tricky maze in reverse. Saying "We don't make any promises regarding revival" just leads to inconsistency, and make the bugs subtler. The advantage of the __close__ semantics is that it greatly reduces the number of unbreakable cycles; this still doesn't avoid corner cases, but it simplifies the average case, and therefore the typical user experience. -jJ _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
