Question

This question is an extension of a question I asked earlier: Python Delegate Pattern – How to avoid circular reference? After reading the replies, I decided to clarify my question, but was requested to post it separately.

Here goes:

1. A passage in the Python docs (reproduced below) states that garbaged collection is not guaranteed for circular
   referenced objects. A post I found here suggests the same thing. But the replies to my earlier question disagrees. So, have I misunderstood the passage or are there further
   details that I’ve missed?
2. I suppose using a weak reference, as stated in Alex Martelli’s reply to the question Should I worry about circular references in Python? would avoid the overhead for garbage collecting circular referenced objects mentioned in his reply entirely? If so how does it work?

The relevant Python docs that suggests conflicting following passage from Python’s doc:

CPython implementation detail: CPython currently uses a
reference-counting scheme with (optional) delayed detection of
cyclically linked garbage, which collects most objects as soon as they
become unreachable, but is not guaranteed to collect garbage
containing circular references. See the documentation of the gc module
for information on controlling the collection of cyclic garbage. Other
implementations act differently and CPython may change. Do not depend
on immediate finalization of objects when they become unreachable (ex:
always close files).

The passage in its original form can be found here: http://docs.python.org/reference/datamodel.html The bold setting is mine.

Thanks in advance for any replies.

Answer 1

I believe that the most important reason that objects with circular references aren’t guaranteed to be collected is that, by design, Python never collects objects with circular references if they define a __del__ method. There is a pretty straightforward reason:

Python doesn’t collect such cycles automatically because, in general, it isn’t possible for Python to guess a safe order in which to run the __del__() methods.

I am loath to say that this is the only reason unreachable objects with circular references might not be detected. There are probably a few unusual situations that could foil the GC’s cycle detection mechanisms. But unless you define __del__ for one of your objects, you’re probably ok. Just don’t worry about it, and use the GC’s extensive debugging options if you see performance issues.