__del__ problem - would adopting Garbage Collection fix this?

Greg Ewing greg at cosc.canterbury.ac.nz
Wed Apr 19 23:53:02 EDT 2000

Michael Hudson wrote:
> "Warren Postma" <embed at geocities.com> writes:
> > 2. Is this convincing proof, or not, that Garbage Collection would
> > be a Good Thing.
> 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.

Actually, it might. The reason that Py_Finalize
explicitly destroys module namespaces is to break
the circular references that occur between the
module dictionary and the functions defined therein.
With true GC, breaking references in an arbitrary 
order like that would no longer be necessary.

Although another set of problems would then crop
up, concerning in what order to finalise objects
that reference each other. Last time this was
discussed, I think we decided that the simplest
option was simply not to call the __del__ methods
of unreachable objects participating in cycles.
The __del__ method would only be called if the
object was collected as a result of its refcount
dropping to 0.

The destructors of C objects would still have
to be called, so that resources external to the
Python system (files, windows, etc.) would be
reclaimed. Such C destructors would have to be
careful about making any callbacks to Python
code (preferably not do it at all).

Another option would be to call all __del__
methods of all the objects about to be reclaimed
first, then free the memory (after checking that
none of them have been resurrected).

Either way should reduce the chance of having
something disappear out from under you unexpectedly
in a __del__ method.

By the way, does anyone know what the recently
announced GC patch does about __del__ methods?

Greg Ewing, Computer Science Dept,
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+

More information about the Python-list mailing list