[Python-3000] Removing __del__

[Carl Friedrich Bolz]

Jim Jewett wrote:
> 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 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