__del__ problem - would adopting Garbage Collection fix this?

[Warren Postma]

I have received a helpful not explaing that the C function Py_Finalize does
not
always correctly figure out the right order in which to destroy things.

The usual hack to work around this is like this:

        def myclass:
            def __del__(self,foo=foo): #ensure symbol foo is not freed
                foo.bar() # call foo method in destructor without worry

Another similar hack I am now using:

        def myclass:
            _foo=foo
            def __del__(self):
                self._foo.bar()  # class variable _foo (1 per class)

My questions:

1. Shouldn't freeing modules in Py_Finalize be in the reverse order of the
way in which the modules were created?  Could a module-destruction order be
explicitly maintained by the system?

2. Is this convincing proof, or not, that Garbage Collection would be a Good
Thing. Is JPython immune to these bizarre behaviours?

3. What about adding a __finalize__ method to objects.  Python could then
finalize all objects first, and then delete them, and the rule is you ONLY
EVER USE __del__ when you Absolutely Have to, and with some known issues
(such as this). In other words, all objects are finalized in Py_Finalize,
then destroyed. When an object is deleted with del(obj), it is finalized
first, then freed.

4. Until such point as there is a __finalize__, I am actually going to
explicitly call a finalization method, then delete objects. Side effects on
Destructors can arguably be a Bad Thing.

Any other thoughts?

Warren