I Love Trash

Tonight, I’m on page 126 of my Learning Python book. (It’s not exactly a page-turner.)

So far, no mention of mandatory source code indentation, except as the briefest aside. It’s a bit amusing how it’s the first thing everyone thinks of, yet my tutorial is playing coy. Well, be that way, you tease!

One thing it does mention is circular, or “cyclical” references. Object A refers to object B, which refers to object A.

>>> A = ['tiger']
>>> A.append(A)
>>> A
['tiger', [...]]

In the above case, an entry in list A refers to list A itself. So if you tried to print A, you’d get an infinitely long list.

But Python detects this case, and substitutes [...] instead. I’m going to assume this is list-specific, but that Python does this even just for standard types is heartening.

Does Python apply the same kind of logic when implementing automatic garbage collection? Will it recognize that a list, whose only remaining reference is from an unreferenced object within that list, can be gc’ed?

Per this page, the answer would appear to be yes: “Fortunately, Python’s cyclic-garbage collector will eventually figure out that the list is garbage and free it.”

The rest of that page, however, seems to imply that for more complicated custom classes, sometimes you need to take care of cyclical references yourself.

Is that a rare case? Or an inevitable gotcha as you start writing more complex Python programs?

My book is mum on the subject.


  1. katre

    I haven’t done large complicated programming with python where memory management become a big thing, but I recall reading that Python uses a refcounting GC system. What this means is that circular reference chains won’t get collected because the refcounts will never drop to 0. So it’s probably safest to break your cycles when you finish with them.

  2. Joe Mason

    For a long time Python used pure refcounting, but fairly recently they added a cycle detector that runs periodically. So I think (but don’t quote me on this) that you don’t have to worry about cycles at all any more (except maybe when writing C extensions). Your book may have been written before the cycle-detector was added, and only partially updated.

    (I guess the cycle-detector is a standard mark-and-sweep collector, so they could probably remove the refcounting altogether and just run the mark-and-sweep more often. I wonder what the performance characteristisc of the hybrid are.)