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
-- http://mail.python.org/mailman/listinfo/python-list
