CPython's cyclic garbage collector (was [Python-ideas] Automatic context managers)

[Chris Angelico]

On Sat, Apr 27, 2013 at 8:50 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Fri, Apr 26, 2013 at 10:54 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> Once it's been proven that there's an unreferenced cycle, why not
>> simply dispose of one of the objects, and replace all references to it
>> (probably only one - preferably pick an object with the fewest
>> references) with a special temporary object? In fact, that could
>> probably be done in CPython by wiping out the object in memory and
>> replacing it with a special marker of some sort, which would then
>> automatically "take over" all references to the old object. Any
>> attempt to manipulate this object could simply pop back with a
>> DestructedObject exception or something.
>
> I think it still boils down to the same problem -- how should Python
> *predictably* choose which object will be disposed of in order to
> break the cycle?  I don't see that this question is any different than
> asking how should Python choose which __del__ method should be called
> first, since the object so disposed of would still need its __del__
> method called.

It wouldn't need to. It just chooses arbitrarily. Maybe it picks the
one with the lowest id(), maybe it picks the object that takes up the
most space, maybe the one that would have been put into gc.garbage
first. But it's got to die tomorrow, so it really doesn't matter[1],
and there's no way for the GC to know which one won't be referenced by
the other's __del__ method.

[1] I'm involved in a Gilbert and Sullivan Society performance,
curtain up in less than three hours, so I'm morally obligated to quote
G&S somewhere.

ChrisA