the current gc already detects cyclic referencing between objects, <br>and by what i understood, it can free the memory the objects take,<br>but __del__ is never call because there's not telling where to<br>start the __del__ chain.
<br><br>by cyclic referencing i mean something like<br>&gt;&gt;&gt; class x(object):<br>...&nbsp;&nbsp;&nbsp;&nbsp; def __init__(self):<br>...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; self.next = self<br>...&nbsp;&nbsp;&nbsp;&nbsp; def __del__(self):<br>...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; print &quot;deleted&quot;<br>
...<br>&gt;&gt;&gt; y=x()<br>&gt;&gt;&gt; del y<br>&gt;&gt;&gt; import gc<br>&gt;&gt;&gt; gc.collect()<br>2<br><br>while __del__ was never called. you can solve the problem using <br>weakref.proxy, in a fashion like<br><br>
&gt;&gt;&gt; class x(object):<br>...&nbsp;&nbsp;&nbsp;&nbsp; def __init__(self):<br>...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; self.next = weakref.proxy(self)<br>...&nbsp;&nbsp;&nbsp;&nbsp; def __del__(self):<br>...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; print &quot;deleted&quot;, repr(self.next)<br>...<br>&gt;&gt;&gt; y=x()
<br>&gt;&gt;&gt; y<br>&lt;__main__.x object at 0x00B9E190&gt;<br>&gt;&gt;&gt; y.next<br>&lt;weakproxy at 00ADFF60 to x at 00B9E190&gt;<br>&gt;&gt;&gt; y.next.next<br>
&lt;weakproxy at 00ADFF60 to x at 00B9E190&gt;<br>
&gt;&gt;&gt; del y<br>deleted &lt;weakproxy at 00ADFF60 to NoneType at 1E1A1E00&gt;<br><br>so why not do this automatically?<br><br>this idea is to simplify the GC and completely avoid cyclic references <br>between objects. it's quite simple: every time an assignment is made, 
i.e.,<br><br>self.next = self<br><br>the interpreter would automatically detect the assignment would create<br>a cyclic reference, and would instead create a weakproxy instead, i.e.<br><br>self.next = self ==&gt; self.next
 = weakref.proxy(self)<br><br>this approach has several benefits:<br>* the object stays alive only when *external* references to it exist<br>* makes the GC a lot simpler (only refcounts are needed)<br>* __del__ is always called
<br>* the only problem is when __del__ is called, some attributes might<br>refer to None, but that can be easily anticipated by the code of the<br>destructor<br><br>i guess it has a performance penalty... but maybe there can be a
<br>trick around it. i can imagine the code of the INCREF() detecting<br>the assignment yields an increment of two instead of one, and<br>would therefore create a weakref. of coure this optimization is<br>too lax, but something in that direction.
<br><br><br><br>-tomer<br>