What is object resurrection in a `__del__` finalizer, and can it run twice?

### The finalizer receives a fully working object `__del__` is called *before* the object's memory is released, and it is called with `self`. There is nothing weakened or partial about that reference: attributes work, methods work, and the object can be handed to anything. So a finalizer is free to do the one thing that sounds impossible — make the dying object reachable again: ```python registry = [] class Exhibit: def __del__(self): registry.append(self) # the object is now reachable again ``` When the finalizer returns, CPython re-checks the reference count. It is no longer zero, so deallocation is abandoned and the object stays alive, now owned by `registry`. That is resurrection. ### How many times can the finalizer run? This is the part interviewers are actually probing. The language reference says only that it is implementation-dependent whether `__del__` is called a second time when a resurrected object is about to be destroyed, and that CPython calls it once. The mechanism, introduced by PEP 442 in Python 3.4, is a per-object *finalized* bit: the first time CPython invokes the finalizer of a garbage-collected instance it sets that flag, and the flag is checked before any later call. So an object that is resurrected and dropped ten times is finalized once and then freed silently. Two practical corollaries. First, cleanup written in `__del__` genuinely happens at most once, which is convenient but is a CPython promise rather than a language one. Second, an object that resurrects itself unconditionally can never be freed while it keeps re-registering — you have built an immortal object with none of the benefits of one. ### The bigger thing PEP 442 fixed Resurrection is the memorable half of PEP 442; the important half is cycles. Before Python 3.4, if two objects referred to each other and either defined `__del__`, the collector refused to finalize them — it could not decide a safe order in which to run the finalizers, since each one might touch the other after it had been torn down. Those objects were appended to `gc.garbage` and never freed, so any long-running process that formed such a cycle leaked steadily. The standard advice of the era was "never define `__del__` on anything that might take part in a cycle". PEP 442 changed the tear-down order: the collector now runs *all* the finalizers in the unreachable group first, then re-checks reachability, and only then clears and frees the objects. Finalizers therefore see a consistent world, resurrection from inside a cycle is detected, and the finalized flag prevents a second call in a later collection. On Python 3.14 a cycle whose members define `__del__` is collected like any other, and `gc.garbage` stays empty unless something truly uncollectable appears. ```python import gc class Node: def __init__(self, tag): self.tag, self.peer = tag, None def __del__(self): print("finalizing", self.tag) a, b = Node("a"), Node("b") a.peer, b.peer = b, a del a, b gc.collect() print("garbage:", gc.garbage) # both finalized, nothing stranded ``` ### Where this bites in real systems A registry-style resurrection is occasionally deliberate — pooling an expensive object instead of letting it die, for example. It is nearly always the wrong tool: the object comes back carrying whatever state its finalizer left it in, the pool grows with no eviction path, and no reader of the class expects `__del__` to be the constructor for the next lease. A pool with explicit `acquire` and `release` methods, or an explicit re-add on close, expresses the same intent in code someone can debug. The unintentional version is easier to hit: a finalizer that logs `self`, appends to a debug list, or passes `self` to a callback that stores it. The object is silently retained, memory climbs, and because the finalizer already ran it will never run again — so the "cleanup on destroy" the class advertises never happens for that instance. ### What to say in the room "Resurrection means `__del__` stored `self` somewhere reachable, so the object survives its own destruction. CPython sets a finalized flag, so the finalizer runs at most once per object even then; the language calls that implementation-defined. PEP 442 in 3.4 introduced the flag and made cycles with finalizers collectable instead of stranding them in `gc.garbage`."