[Python-3000] Removing __del__

Giovanni Bajo rasky at develer.com
Tue Sep 26 10:59:33 CEST 2006


Raymond Hettinger wrote:

> In short, __del__ should disappear not because it is useless but
> because
> it is hazardous.  The consenting adults philosophy means that we don't
> put-up artificial barriers to intentional hacks, but it does not mean
> that we bait the hook and leave error-prone traps for the unwary.  In
> Py3k, I would like to see explicit finalization as a preferred
> approach
> and for weakrefs be the one-way-to-do-it for designs with implicit
> finalization.

Raymond, there is one thing I don't understand in your line of reasoning. You
say that you prefer explicit finalization, but that implicit finalization still
needs to be supported. And for that, you'd rather drop __del__ and use
weakrefs. But why? You say that __del__ is harardous, but I can't see how
weakrefs are less hazardous. As an implicit finalization method, they live on
the fragile assumption that the callback won't hold a reference to the object:
an assumption which cannot be enforced in any way but cautious programming and
scrupolous auditing of the code. I assert that they hide bugs much better than
__del__ does (it's pretty easy to find an offending __del__ by looking at
gc.garbage, while it's harder to notice a missing finalization because the
cycle loop involving the weakref callback was broken at the wrong point).

I guess there's something escaping me. If we have to drop one, why is that
__del__? And if __del__ could be fixed to reliably work in reference cycles,
would you still want to drop it?

Giovanni Bajo



More information about the Python-3000 mailing list