__del__ problem - would adopting Garbage Collection fix this?
chega_ at yahoo.com
Fri Apr 21 09:29:02 CEST 2000
"Just van Rossum" <just at letterror.com> wrote in message
> >"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
> 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
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
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.
More information about the Python-list