[Python-3000] Removing __del__
Jim Jewett
jimjjewett at gmail.com
Fri Sep 22 19:52:17 CEST 2006
On 9/22/06, Carl Friedrich Bolz <cfbolz at gmx.de> 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
More information about the Python-3000
mailing list