super not working in __del__ ?

[Jeff Shannon]

Christopher J. Bottaro wrote:


> So encapsulating your script in a main function fixes the problem:

Not necessarily.

> because all the objects instantiated in main() will be deleted when main
> ends, but before the interpreter shuts down, thus the objects will have
> access to all the symbols in module's __dict__ (or however that works).

What about default function parameters?  Those can't be cleaned up 
until the function is deleted.  What about class attributes, which 
can't be cleaned until the class is deleted?  What about objects which 
have had references passed to other modules?  What about sets of 
objects with cyclical references?

There's too many corner cases and special cases for this to be 
reliable.  Cutting down on module-global variables will help (and is a 
good idea anyhow), but it's not perfect.

I'm just guessing, here, but I'd imagine that it might be possible to 
modify the interpreter so that, at shutdown, it carefully builds 
dependency trees and then walks through them in reverse, deleting 
objects in the "proper" order, and trying to handle cycles as sanely 
as possible.  You could probably get the __del__ of almost every 
object to be fairly reliable.  But that's a lot of work to go to when 
99% of the time all you need to do is flush the entire block of 
memory.  (By 'a lot of work', I mean both in execution time causing 
the shutdown of Python to be notably slower, and in developer time 
writing such a fancy shutdown scheme.)  It's much more practical to 
just say that __del__() is not reliable (especially given some of the 
other issues with it, such as cyclic references, etc.) and suggest 
that people write their code in such a way that it isn't required.

Python's __del__() is not a C++/Java destructor.  Trying to make it 
into one is unlikely to give an overal benefit.

Jeff Shannon
Technician/Programmer
Credit International