Why does a callback registry holding obj.method keep that instance alive in Python?

### What `obj.method` really is `obj.method` is not the function written in the class body. Attribute lookup builds a **bound method object**: a small wrapper carrying two attributes. `__func__` is the plain function taken from the class `__dict__`, and `__self__` is the object the call will pass as the first argument. Calling the wrapper is calling `__func__(__self__, *args)`. The wrapper is constructed on each lookup, by the protocol that turns a function stored on a class into a bound callable; the details of that protocol are a topic of their own, but its output — a fresh wrapper holding the instance — is what causes the behaviour below. `__self__` is an **ordinary strong reference**. Nothing about it is weak, and no special case exempts it from the reference counting that governs every other attribute. So a container that holds a bound method holds the instance behind it, transitively holding everything that instance references. ### The failure this produces A feature-flag service registers a callback per cache object — `registry.append(cache.reload)` — and drops the cache when the flag definitions are reloaded. Each reload builds fresh cache objects for the 6,800 flag rows and appends fresh callbacks. Nothing removes the old entries, so every generation of caches stays alive through `__self__`, along with the parsed flag data each one holds. Resident memory climbs in flat steps, one step per reload; there is no cycle to blame, no `__del__` doing anything strange, and the objects look perfectly ordinary in a heap dump apart from being referenced by a list of bound methods. The registry is the leak, and the bound method is how it holds on. Anything that stores callables has this shape: signal and event registries, retry and scheduler queues, `atexit` handlers, cache entries keyed to a callback, worker pools handed a method to call. ### The second consequence: identity Because a new wrapper is built on every lookup, `obj.method is obj.method` is `False` while `obj.method == obj.method` is `True` — same `__func__`, same `__self__`, different wrapper objects. Two practical results: - Unregistering by identity fails silently. Code that scans a list comparing with `is`, or keys a dict on `id()`, will never find the entry it registered. Removal by equality (`list.remove`, or membership in a `set`, since bound methods hash consistently) does work. - If identity matters — you want to remove exactly what you added — bind once, keep that object, and register and unregister *that*. ### The fixes - **Own the lifecycle.** The simplest correct answer is usually an explicit `unregister` at the point the object is discarded, or a context manager around registration. Most "leaks" of this shape are missing removals, not missing weakness. - **Hold the instance weakly and re-bind at dispatch.** Store a weak reference to the instance plus the plain function, and reconstruct the call when firing; drop entries whose referent has died. The standard library also ships a weak-reference wrapper made specifically for bound methods, which packages exactly this. - **Register a plain function that takes the object as an argument**, and let the caller own the lifetime. - **Do not** try to fix it by storing `Cls.method` and passing the instance separately unless you have somewhere to keep the instance weakly — otherwise you have just moved the strong reference. ### The neighbouring facts interviewers check - `Cls.method` is the plain function, with no `__self__` at all. `Cls.method(obj)` is the unbound call and does the same work as `obj.method()`. - On a `@classmethod`, `__self__` is the *class*: `Cls.build.__self__ is Cls`. Since classes are usually module-level and immortal for the process, this rarely leaks anything interesting. - A `@staticmethod` looked up through either the class or an instance is just the function — no binding, no `__self__`, and `inspect.ismethod` returns `False` for it. - Built-in methods behave the same way: a list's `append` accessed off a list instance carries that list in `__self__`, which is why passing it as a callback pins the list. - `types.MethodType(func, obj)` constructs a bound method by hand, which is how you attach a callable to one single instance rather than to its class. - `functools.partial(Cls.method, obj)` produces a different object with the same retention property — the instance is still held strongly, just in the partial's arguments instead of in `__self__`. ### How to confirm it in a live process Take a weak reference to a representative object, drop your own reference, force a collection, and see whether the referent survives. If it does, walk the referrers to find who is holding it; a list of bound methods is unmistakable once you look at what the referring objects are. This is a retention problem rather than a cycle problem, so the cycle collector will never clear it: the reference is real, reachable and exactly as intended by the code that created it.