Jim Jewett wrote: > 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 helps by removing many corner cases in the GC that come from objects reviving themselves (and putting themselves into a cycle, for example). It makes reviving an object perfectly ok, since the strange things start to happen when an object continuously revives itself again and again. > 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). But the above proposal is independent from the question how cycles with finalizers get resolved. We could still say that it does so in an arbitrary order. My point is more that just allowing objects to be finalized in arbitrary order does not solve the problem of objects continuously reviving themselves. > 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. See above. Calling __del__ once is an independent issue from how to break cycles. Cheers, Carl Friedrich Bolz _______________________________________________ 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
