Final garbage collection?

[Martin von Loewis]

Jerome Quelin <jerome.quelin at insalien.org> writes:

> I was wondering why Python does not implement such a mechanism, that
> seems to me a Good Thing (tm), because _in final_, every object _is_
> destroyed, either if their reference count is nul or not, since the memory is
> reclaimed by the system.

I think the primary reason for that in Python 1.5 (and before) is that
the interpreter does not keep track of all objects. So if a cycle
becomes garbage, it really *is* garbage - the interpreter does not
even know the cycle is there. To release the cycle at the end of the
program, you'd have to keep track of all objects. That would increase
the size of an object, and slow down object creation.

In Python 1.6 (starting with beta1), there will be 'true' garbage
collection. One of the downsides is that it therefore will have to
keep track of all objects. In your original example, I believe Python
1.6 still wouldn't collect your objects, as they have __del__
finalizers - which pose a big problem to a garbage collector.

As for cleaning up all objects at the end: If the objects have
finalizers, this is very difficult. What if the finalizer choses to
access an object that was already cleaned-up, or choses to bring the
object back into life? If programs are suddenly exposed to
cleanup-at-end, most would probably run in some problem and raise an
exception. That, in turn would invoke cleanup, which would start
cleaning the same object, which would throw an exception, etc....

Regards,
Martin