does python have useless destructors?

Roger Binns rogerb at rogerbinns.com
Fri Jun 11 16:41:41 EDT 2004


Duncan Booth wrote:
> The object itself can know that it needs to be safely disposed of, but it
> cannot tell *when* to dispose of itself. My example function might create
> multiple objects some of which need disposing when the function returns,
> and others have a longer lifetime. The choice between disposing at the end
> of the function or when some containing object is disposed has to be one
> for the caller.

You have totally confused me now.  Ignoring special cases such as cycles,
Python destructs an object when there are no references left to it,
and in CPython that happens at the moment the last reference is released.
So in normal code the objects will go away as names referencing them go
out of scope.

If the Python object is a proxy for another non-Python visible object
(such as a C level filehandle or GUI Window).  In those cases
the extension module author has to deal with the situation, either by
adding an extra reference (the C level object is then the remaining reference)
or handling the lifetime of the C level object independently.

But for this thread, the actual problem is that __del__ methods may
not be called on objects, and if you read the doc implies they almost
never will be called.  So we have the counter-intuitive (and IMHO user
hostile) situation where someone marks a class as needing extra code
to run to destroy it, and Python addresses that by saying you will
be lucky if the object will be destroyed (ie by not destroying the
object).

The band aid is requiring the programmer/caller to call various
"close" methods (effectively manually calling a destructor equivalent)
with all the issues that entail, get real complex real quick and are
prone to errors or ommissions, and are extremely difficult to test.
And you can see the difficulties in this thread with the issues
of just dealing with a single file handle.

I certainly agree that dealing with destructors from a language
implementor's point of view is hard.  Try dealing with cycles,
resurrection, exceptions etc.  But handwaving and just not
running them coupled with expecting manual code by callers all
over the place is a bad solution.  Garbage collection is also
hard, but all recent languages do it.

Roger





More information about the Python-list mailing list