Re: does python have useless destructors?

From: Roger Binns (rogerb_at_rogerbinns.com)
Date: 06/11/04


Date: Fri, 11 Jun 2004 13:41:41 -0700

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



Relevant Pages

  • Re: does python have useless destructors?
    ... >> between disposing at the end of the function or when some containing ... and in CPython that happens at the moment the last reference is ... C Python destroys an object when no references are left. ... IronPython destroy objects when the underlying garbage collector feels like ...
    (comp.lang.python)
  • Re: Memory Leak due to objects not destroyed
    ... a reference allows them to be shown quickly. ... > using (Form myForm = new Form) ... > I've succeeded in slowing down memory leak by overriding Dispose(bool ... > disposing) method in all our forms so that they set all referenced objects ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Form not disposing due to lingering reference
    ... However, assuming that IsDisposed is false in your handler, I take that as a clear indication that your handler is called during disposal, not after. ... What does the Disposing property return? ... this reference is the only remaining rooted reference to the disposed form. ... A reference inside a ToolStrip instance isn't a rooted reference. ...
    (microsoft.public.dotnet.framework)
  • Re: Memory Manipulation
    ... reference. ... escribió en el mensaje ... A good example of this is an connection object to an Excel spreadsheet ... - even after disposing of this object, ...
    (microsoft.public.dotnet.languages.vb)