garbage collection / cyclic references
castironpi at gmail.com
Sat Mar 21 09:26:28 CET 2009
On Mar 20, 8:12 pm, "andrew cooke" <and... at acooke.org> wrote:
> Aaron Brady wrote:
> > caveats and fragilities? If free software can do it, why isn't it all
> > over the industry? What disqualifies it from solved-problem status?
> the two dominant virtual machines - .net and the jvm both handle circular
> references with no problem whatever. this is standard in modern garbage
> collection - go read a book on the subject (personally i like grune et
> al's modern compiler design). it *is* a solved problem. if anything,
> python is behind the curve, not ahead of it, but this may change with the
> next generation of python implementations (pypy targets a variety of vms,
> i think).
> as for the extra methods you suggest - why do you want to expose
> implementation details in an api? that is not the normal aim of good
"Circular references ...can only be cleaned up if there are no Python-
level __del__() methods involved." __del__ doc.
"Python doesn’t collect ... cycles automatically because, in general,
it isn’t possible for Python to guess a safe order in which to run the
__del__() methods." gc.garbage doc.
"Errors should never pass silently." -The Zen of Python
I advance that cyclic objects should be notified when their external
references go to zero, but their usual '__del__' is inappropriate. If
objects implement a __del__ method, they can choose to implement a
'__gc_cycle__' method, and then just drop the specified attribute. It
needn't be called on every object in the cycle, either; once it's
called on one object, another object's normal __del__ may be safely
called. Output, unproduced:
>>> del x
In X.__gc_cycle__, 'other' attribute. Deleting...
The actual backend of CPython requires garbage-collected container
types to implement tp_inquiry and tp_clear methods, but user-defined
types apparently aren't required to conform.
Supporting Cyclic Garbage Collection
More information about the Python-list