Why does weakref.finalize(obj, obj.close) never fire while the program runs?

## The trap in one line `weakref.finalize` holds a *weak* reference to the referent and *strong* references to everything else you hand it. If what you hand it can reach the referent, you have quietly built a strong reference from a process-lifetime registry back to the object you wanted collected. ## Why a bound method is the usual culprit Writing `obj.close` does not name a function on the class — it builds a new **bound method** object on the spot, and that object stores the instance in `__self__`. So `weakref.finalize(obj, obj.close)` stores, in the registry: * a weak reference to `obj` (harmless), and * a bound method that strongly references `obj` (fatal). The second one wins. `obj`'s reference count never drops to zero and the cyclic collector cannot help either, because the registry is a live root, not garbage. The finalizer stays `alive` forever. ```python import gc, weakref class Handle: def close(self): print("closed") h = Handle() f = weakref.finalize(h, h.close) # bound method pins `h` del h gc.collect() print(f.alive) # True - nothing was collected ``` The same shape hides in `lambda: obj.close()`, in `functools.partial(some_func, obj)`, in a default argument such as `func=obj.flush`, and in an object graph one level deeper: a logger you pass as an argument that happens to hold a back-reference to `obj`. ## What actually happens instead of nothing The failure is not "the callback is lost" — it is worse, because it looks like it works. The finalizer is still registered, so at interpreter shutdown the exit pass calls it. So the resource does get released, five hours late, during shutdown, along with every other deferred finalizer at once. In a long-running process the symptom is a slow climb in descriptors, temp files or memory that vanishes the moment you kill the process for investigation — the least helpful bug shape there is. ## The fix: capture the resource, not the owner Ask what the cleanup genuinely needs. Almost always it is a small, plain value: an integer file descriptor, a path string, a socket, a connection handle from a lower layer. Pass those. ```python import os, tempfile, weakref class Scratch: def __init__(self): fd, self.path = tempfile.mkstemp() self._finalizer = weakref.finalize(self, os.close, fd) ``` Note what is safe here. Storing the finalizer *on* the instance is fine: the arrow points from the object to the finalizer, and the finalizer holds only a weak reference back, so there is no cycle and no pinning. `os.close` is a module-level function that knows nothing about `Scratch`. The captured `fd` is an `int`. When the cleanup is more than one call, use a module-level function or a `staticmethod` that takes exactly the pieces it needs, and pass those pieces. If you find yourself wanting `self` in the body, that is the signal that the cleanup logic should be split: the part that touches the resource moves out of the class, and the part that touches the object's state cannot run at finalization time anyway. ## How to catch it It is directly testable, which is why interviewers like it. Drop the last strong reference, force a collection, and assert the finalizer is dead: ```python obj = MyThing() f = weakref.finalize(obj, cleanup, obj.resource_id) del obj gc.collect() assert not f.alive ``` A regression test of that shape around any class that registers a finalizer costs three lines and catches the day someone "simplifies" the registration back to a bound method. `weakref.ref(obj)` plus `gc.collect()` gives the same assertion for objects you did not register anything on. ## The mirror-image mistake The opposite error is capturing something the callback needs and then having it die first. Anything the callback touches at exit time — a module global, an open stream, a logger — may already be torn down when the exit pass runs. Keep finalizer callbacks tiny, dependency-free, and tolerant of being called into a shutting-down interpreter.