Explanation of Python's Garbage Collection

PYTHON GARBAGE COLLECTION 1) REFERENCE COUNTING (immediate, deterministic) Every object keeps an integer refcount. When you bind a name, append to a list, store in a dict, etc., the count goes up; when a reference goes away (del, rebinding, container deleted), it goes down. At zero, the object is freed instantly — its memory returned and __del__ (if any) called right then. This is why most Python objects are cleaned up the moment they're no longer reachable, with no "stop the world" pause. 2) GENERATIONAL CYCLE COLLECTOR (for the blind spot) Refcounting alone cannot free objects that reference each other in a cycle: each holds a reference to the other, so neither ever hits zero, even when no external name reaches them. The cycle collector tracks only container objects (list, dict, set, tuple, custom class instances, etc.) in three generations (0, 1, 2). New tracked objects go to gen0; each collection that survives promotes it up a generation. Collections of gen0 are frequent and cheap; gen2 is rare and expensive. When it runs, it finds unreachable cycles by subtracting internal references and frees the whole island at once. 3) WHY __del__ IS DANGEROUS - Order is undefined: in a cycle, Python cannot know which object's __del__ to run first, so it may call them in arbitrary order or skip them entirely (they go to gc.garbage). - Resurrection: __del__ can stash a reference to self (or another dying object) in a global, reviving the object and breaking the collector's bookkeeping. - Exceptions in __del__ are printed to stderr, not raised, so bugs hide. - It can resurrect objects, causing them to never be collected. - It makes objects uncollectable-by-refcount until the cycle collector runs, so cleanup becomes non-deterministic. Modern practice: avoid __del__; use context managers (with), weakref.finalize, or atexit handlers instead. MINIMAL DEMO class Node: def __init__(self, name): self.name = name self.other = None def __del__(self): print(f"deleting {self.name}") a = Node("a") b = Node("b") a.other = b b.other = a # reference cycle: a <-> b del a, b # refcounts never hit 0 -> __del__ NOT called import gc print("collected:", gc.collect()) # cycle collector finds and frees them # output: deleting a / deleting b / collected: 2 If you run it, you'll see the __del__ messages only appear after gc.collect(), proving refcounting alone missed the cycle. WHEN TO USE weakref INSTEAD - Caches / memoization: a cache should not keep objects alive. weakref.WeakValueDictionary lets entries vanish when the value is otherwise garbage. - Parent/child or observer/callback relationships: a child holding a strong ref to its parent (or a listener holding the subject) creates cycles and keeps things alive unintentionally. A weakref breaks the cycle without __del__. - Object identity tracking: weakref.WeakSet to track all live instances of a class without pinning them in memory. - Weak references do NOT keep the referent alive; when the referent dies, the weakref returns None (or the callback fires). Use weakref.ref(obj), .() to dereference, or the WeakKeyDictionary / WeakValueDictionary / WeakSet containers. Rule of thumb: use weakref whenever a reference is only for convenience/lookup, not for ownership. If you need cleanup when an object dies, prefer weakref.finalize over __del__ — it's deterministic and doesn't interfere with the collector.