> Unfortunately I don't know if __del__ will always be called during a
> normal finalization. I haven't read the source, and the documentation
> merely says, "It is not guaranteed that __del__() methods are called for
> objects that still exist when the interpreter exits."
>
> It looks like problems related to __del__ have already been reported in
> Quixote:
>
> http://mail.mems-exchange.org/pipermail/quixote-users/2004-March/002733.html
>
> In short, I'd rather clean up explicitly. ;-)


Thanks for the clarification.  I either forgot or never knew that bit about
finalization code being 'optional' in Python.

Martin Maney also replied off list with:

>> Am I missing something about the way the interpreter behaves as a process is
>> wrapping up?
>
>Only if you're assuming that the interpreter necessarily bothers to
>collect garbage created by the termination of the program.  Why bother
>to recycle memory that's about to be abandonded back to the OS anyway?
>Nope, running finalizers isn't a reason, at least not in Python's GC
>model.  Finalizers are there to help GC out, not the other way around.
>
>"Objects are never explicitly destroyed; however, when they become
>unreachable they may be garbage-collected. An implementation is allowed
>to postpone garbage collection or omit it altogether..."
>
>  http://www.python.org/doc/2.3.4/ref/objects.html#l2h-18


Learning all the time!  I guess this makes yet another example of why explicit
programming is better than relying on 'cool tricks' of the language!  (Now, I
need to go revisit a few programs I have lying about that may be relying on the
__del__() method.)  I guess the appropriate use of __del__(), then, is to use
it for clearing out in-memory resources that can be safely forgotten about in
the case of an interpretter shutdown.  All resources that exist (or have
components which exist) outside of the interpretter should be handled
explicitly, ideally in a finally block, or the like.

Jason