Why does a Python closure keep a large captured object alive, and how do you avoid it?

## The mechanism, stated precisely When a nested function closes over a name, the compiler moves that variable into a **cell** and gives the function object a reference to it in `__closure__`. The cell holds one ordinary strong reference. Reachability then follows a simple chain: whatever holds the function object holds the cells, and the cells hold the captured values. Nothing about the closure is weak or lazy, and the enclosing frame returning changes nothing — the frame is gone, the cells are not. That is unremarkable for a closure that is called and dropped. It becomes a memory problem exactly when the function object is stored somewhere long-lived: a dispatch table, an event-handler registry, a list of pending compensating actions, a cache of prepared callables. ## The shape it takes in practice Consider a webhook receiver that, for each event it accepts, builds a small callable to undo the work if a later step fails, and parks it in a pending-rollbacks dict until the transaction completes. The natural code closes over the parsed event so the rollback can quote an identifier in its log line. The rollback only ever touches one short string — but the cell holds the whole parsed event: the raw body, the decoded JSON, whatever the parser attached. Retention is per **object**, not per attribute. While everything succeeds promptly, nothing shows. The failure mode arrives with a partial-failure rollback path: entries that are only removed on the success path accumulate whenever a downstream step half-fails and the cleanup misses a branch. Each stuck entry pins a full payload. On a worker with a 45-second cold start, the operator's instinct is to leave processes up for a long time rather than recycle them, which is precisely the condition under which slow retention becomes visible — the same code on short-lived processes would never have shown a symptom. The tell that distinguishes this from ordinary growth is that the retained objects are not obviously referenced from anywhere in your data model. They are reachable only through a function object, and function objects rarely feature in a mental map of where data lives. ## Fixes, strongest first **Capture the narrow value.** Bind exactly what the inner function needs to its own local *before* the `def`, and reference that name inside. `event_id = payload["id"]` above the nested function means the cell holds a short string and the payload is free the moment the enclosing call ends. This is the fix that removes the problem rather than managing it, and it costs one line. **Do not capture at all — pass an argument.** `functools.partial(handler, event_id)` produces a callable with the value in its arguments rather than in a cell. That does not make the reference weaker, but it does make it visible: the retained value is a plain attribute of the partial object, obvious to anyone reading it and to anything walking the structure. **Own the lifetime of the registry entry.** Remove the entry in a `finally`, so that no failure path can leave a callable parked. Retention through closures is nearly always a symptom of a container that is easier to add to than to clear. **Hold a weak reference deliberately.** If the closure should observe an object but not own it, capture a `weakref.ref` and call it inside, handling the `None` you get once the object is gone. This is the right tool when the object has a real owner elsewhere, and the wrong one when it does not — you have then converted a memory bug into an intermittent `None`. **Restructure into an object.** When several closures share captured state, a small class makes the retained references plain attributes: visible in a debugger, easy to clear, easy to reason about. ## Two things not to do Emptying the cell from outside — `del f.__closure__[0].cell_contents` — does release the value, and the next call of that function raises `NameError`. It is a legitimate emergency lever and a terrible design; if you can reach the function to empty its cell, you can drop the function. Assuming the cycle collector will handle it is also wrong-headed. The value is not garbage: it is reachable through a live registry entry, and a reachable object is never collected. Cycles are a separate concern; this is plain retention, and only dropping the reference fixes it. ## The reviewable rule When a function object outlives the call that created it, treat its captured names as fields of a long-lived record and ask of each one whether it should be there. That single habit — applied at the `def`, in review — catches nearly all of these before they become an operational puzzle.