No destructor

[Paul Duffin]

Alex Martelli wrote:
> 
> "Paul Duffin" <pduffin at hursley.ibm.com> wrote in message
> news:39A3A1AE.7238075C at hursley.ibm.com...
>     [snip]
> > I don't really see that the order in which you call the destructors is a
> > problem. You simply need to define (and enforce) the rules about what the
> > destructors can and cannot do in this case.
> 
> Unfortunately, what a destructor can reliably do, if any
> reference the object holds may be invalid (and it has no
> way to check), is "just about nothing".  E.g., can it
> reliably call self.foo.close() on a file-like object to
> which it's holding a self.foo ref? No, because self.foo
> might have been part of a circular chain, including this
> object 'self' as well, and have been finalized already.
> 
> At the very least, there should be a way to ask the system
> whether any given reference one has is still valid/usable
> (is to a non-yet-finalized object); so the call becomes
> something like:
> 
>     def __del__(self):
>         if self.foo and sys.valid(self.foo):
>             self.foo.close()
>             self.foo=None
> 
> But this is still far from satisfactory -- nor is it
> all that useful; after all, self.foo will have to have
> "self-closed" if it's happened to be finalized before
> this 'self', so it will also similarly "self-close" if
> it finalizes afterwards itself.  So the call to the
> self.foo.close method cannot really be very important
> to make; what *real* important tasks can __del__ really
> perform if the references it holds can just have
> disappeared from under its nose...?
> 

If all that __del__ is doing is cleaning up references to
other objects then the garbage collector combined with the
default cleanup that Python does for all objects is 
sufficient. 

Your example above assumes that the file like object 
self.foo is part of the cycle which is being cleaned up,
if it is not then it is important that __del__ is
called so that it can be explicitly closed.

> There may be some cases in which an object is holding
> references to things "it just knows for sure" _can't
> possibly_ be part of a circular chain of references,
> and *must* be "properly terminated" by the object as
> they just can't be made capable of self-terminating.
> But it doesn't seem that examples of this spring to
> mind easily.
> 

See above for an example.