No destructor

[Paul Duffin]

Alex Martelli wrote:
> 
> > because of this i've never been able to let myself rely on
> > the __del__ destructor. (will it be called???) will the new
> > garbage cleanup in 2.0 fix this problem?
> 
> GC and reliable-finalization never seem to cooperate 100% in
> any language or environment I know of.  Sure, with GC, circular
> references will not mean automatic resource leaks, which is
> no doubt a gain, but, consider for example -- in WHAT order
> would the objects' __del__ methods be called?  I know of no
> way to ensure a good result.
> 

I know that there are all sorts of issues about finalising, e.g. what
happens if as a result of calling the destructor the object being 
destroyed now has an external reference, ...

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.
e.g.
	Assuming that A and B each hold the only remaining counted 
	reference to each other.

	The garbage collector creates a counted reference to each one.

	The GC calls A's destructor which probably breaks the link
	to B but B is not destroyed because the GC still holds a 
	reference to it. A cannot rely on any information that B has
	because B may have been freed before A.

	The GC calls B's destructor which probably breaks the link
	to A. The A object still exists so B can still use A, it
	just cannot rely on any information that A has.

	If the GC holds the last reference to A or B then it frees the
	storage, otherwise it just releases its reference to them. This
	means that it is possible for the destructor to be called multiple
	times and the destructor must be able to cope with it.