__del__ problem - would adopting Garbage Collection fix this?

[Vadim Chugunov]

"Just van Rossum" <just at letterror.com> wrote in message
news:l03102802b5245023a247@[193.78.237.147]...
> >"Warren Postma" <embed at geocities.com> writes:
> >I don't think so.  You still have to destroy things; true gc might
> >help I suppose, but I'm fairly sure it doesn't solve the problem
> >completely.
>
> I'm not sure if I understood it correctly, but I think the newly proposed
> garbage collector does *not* call __del__ if the object in question is part
> of a cycle. It seems indeed impossible to do so correctly. I think the site
> explained quite well why this is, but I can't seem to repeat it off the top
> of my head.

If you are not going to settle for anything less than a perfect solution, than
this is indeed impossible.
On the other hand, I do remember Python prophets saying that "practicality beats
purity" :-)).

Ask yourself: "What kind of stuff do I typically do in __del__ methods?".
Close files, close sockets, write "Good-bye" to stdout... SWIG generated code
would call a destructor of the wrapped object.
And, I think, that's about it.

Note, that __del__ does not usually involve access to sibling objects
participating in the cycle.  (assumption)
IMHO, this means that we can:
1. pick any PyInstanceObject that comes along and call it's __del__ method.
2. change object's __class__ to, say, DeletedObject (which is defined as   class
DeletedObject: pass)
3. clean out instance __dict__, which will hopefully break the cycle.
4. repeat as needed.
If anyone *does* break the above assumption, well, life is tough...  They will
get an AttributeError exception.
Actually, step 2 above is optional.  It is there just to make possible an
explicit check for deleted objects.

Vadim