When does a `weakref.finalize` callback actually run in CPython?

`weakref.finalize(obj, func, /, *args, **kwargs)` registers a **callback to be run when `obj` is destroyed**, and returns a *finalizer object* that lets you inspect, invoke or cancel that registration. Nothing is executed at registration time; the call only records the intent. **What it actually registers.** The finalizer holds a *weak* reference to `obj`, so it never keeps the object alive, plus **strong** references to `func`, `args` and `kwargs` — it must, because it has to be able to call them later. It also enters itself into a module-level registry inside `weakref`, which is why you never have to keep the returned object in a variable of your own; binding it to a name is only useful when you want to query or cancel it later. **When the callback runs.** There are three ways it can fire and one way it can be cancelled, and the first thing to happen wins, because a finalizer runs **at most once**: 1. **The referent is garbage collected.** In CPython that usually means the moment the last strong reference to `obj` goes away and its reference count reaches zero, so it feels prompt and deterministic; when `obj` is reachable only through a reference cycle it happens later, when the cycle collector runs. The object is already being torn down at that point, which is why the callback receives the arguments you captured rather than the object. 2. **The interpreter exits.** If the object is still alive when the program shuts down and the finalizer's `atexit` flag is true (the default), the callback is called during shutdown. Those exit-time callbacks run in **reverse order of registration** — newest first — mirroring the usual "unwind in the opposite order you set up" convention. 3. **You call the finalizer yourself.** `fin()` runs the callback immediately and returns whatever `func` returned. This is what lets a `close()` behave the same whether or not anyone remembers to call it: an explicit call does the work now, and the registration covers the case where nobody does. 4. **Never**, if you cancel it first. After any of those, `fin.alive` is `False` and further calls return `None`. **Inspecting and cancelling.** `fin.alive` is a boolean: true while the callback is still pending. `fin.peek()` returns the `(obj, func, args, kwargs)` tuple while the finalizer is alive and `None` afterwards — note that peeking hands you back a *strong* reference to the object, so do not stash the result. `fin.detach()` returns the same tuple and **unregisters** the finalizer, so the callback will never run. `fin.atexit` is a writable attribute: setting it to `False` says "run this when the object dies, but not merely because the program is ending". That distinction matters for cleanup that is pointless or actively unsafe at shutdown — flushing a cache the process is about to drop anyway, or writing to a connection in an interpreter that is already half torn down. **Why the exit leg behaves better than shutdown-time `__del__`.** A `__del__` body that runs during interpreter shutdown can find module globals already cleared, so a name it expected to import may be `None` by the time it looks. The `atexit` leg of a finalizer is driven from `weakref`'s own shutdown hook while the interpreter is still in a usable state, and the callable plus its arguments were captured back at registration time rather than looked up when the callback fires. That is why an exit-time finalizer is a far less surprising place to put "release the thing". **What it does not promise.** A finalizer is a best-effort net, not a transaction. If the process dies through `os._exit()`, an uncatchable signal, or a hard crash, no Python-level cleanup runs at all — a finalizer no more than any other exit handler. Timing is also implementation-dependent: the prompt "fires the instant the last name goes away" behaviour comes from CPython's reference counting, and a runtime with only a tracing collector will run the same callback at an unpredictable later moment, or not before exit at all. Cleanup that must happen at a known point still belongs in an explicitly scoped release; the finalizer is the backstop for the object that escaped that scope. One correctness note while wiring one up: because the finalizer keeps `func` and the arguments strongly, passing anything that refers back to `obj` — a bound method of `obj`, say — keeps the object reachable, and the collection leg can then never fire. Pass the plain data the cleanup needs (a descriptor, a path, a name) rather than the object. Interview-wise, the answer that lands is the two-legged one: **object death or interpreter exit, whichever comes first, exactly once** — plus knowing that `atexit = False` removes the second leg and `detach()` removes both.