[Python-3000] Removing __del__
jimjjewett at gmail.com
Tue Sep 19 17:54:30 CEST 2006
On 9/19/06, Michael Chermside <mcherm at mcherm.com> wrote:
> The following comments got me thinking:
> > Statistics incontrovertibly prove that people who habitually
> > avoid __del__ lead happier lives and spend fewer hours in therapy ;-)
> Adam Olsen:
> > I agree here. I think an executor approach is much better; kill the
> > object, then make a weakref callback do any further cleanups using
> > copies it made in advance.
> Since we're apparently still in "propose wild ideas" mode for Py3K
> I'd like to propose that for Py3K we remove __del__. Not "fix" it,
> not "tweak" it, just remove it and perhaps add a note in the manual
> pointing people to the weakref module.
The various "create a separate closer object instead" recipescall seem
to cause a jump in complexity, particularly if you try for a general
I do think we should split __del__ into the (rare, problematic)
general case and a "special-purpose" lightweight __close__ version
that does a better job in the normal case.
For the general case, python refuses to guess about which order to
call __del__ cycles in; this has the unfortunately side effect of
making them immortal.
Almost all actual __del__ uses are effectively a call to self.close().
The call might be required (Tk would leak if tkinter didn't notify
it), or it might just be good housekeeping. The key point is that
order doesn't matter.
In practice they all seem to already be written defensively, so that
they can be called multiple times, or even after teardown has started.
So the semantics of __close__ would be just like those of __del__ except that
(1) It would be called at least once if the process terminates normally.
(2) Call order for linked objects would be arbitrary.
FWIW, I couldn't find a single example in the stdlib (outside of
tests) that wouldn't work at least as well if converted to a __close__
method. (subprocess and popen2 would be harder if __close__ were a
once-only method, like I think generator close ended up becoming.)
More information about the Python-3000