Why can Python's __del__ method run late, never run, or silently hide an exception?

### Finalizer, not destructor The single most useful sentence about `__del__` is that it is a *finalizer*, not a destructor. In a language with scope-bound destruction, an object dies at a syntactically visible point. In Python, an object dies when the runtime decides nothing can reach it any more, and `__del__` is a hook the runtime calls on the way to freeing it. Nothing in the language ties that moment to a line of your code. That produces three separate failure modes, and a good answer separates them. ### 1. It runs later than you think Any surviving handle on the object postpones finalization. Some are obvious — the object is in a list, a cache, a closure, a module global. Some are not: * an exception's traceback holds the frames it passed through, and those frames hold their locals, so a caught-and-stored exception can pin an object indefinitely; * the interactive interpreter keeps the last expression result in `_`; * a debugger, a profiler, or a saved stack frame does the same. The practical symptom is a resource that is "closed by `__del__`" and yet stays open across the whole run, which shows up as exhausted file handles or sockets long before it shows up as memory. ### 2. It may never run at all The documentation makes no promise that `__del__` is called for objects that are still alive when the interpreter exits. Modern CPython in fact finalizes most surviving objects during shutdown, which is exactly what makes this dangerous: it works locally and stops working when the process ends abruptly. Every hard ending skips finalization outright — `os._exit`, a default SIGTERM or SIGKILL, a fatal error in a C extension. And even in the graceful case, ordering during shutdown is not something to build on: the module a finalizer wants to call into may already be tearing down. ```python import os class Res: def __del__(self): print("cleanup ran") r = Res() os._exit(0) # nothing is printed, and nothing is flushed ``` ### 3. Its exceptions vanish `__del__` is called from the deallocation machinery, in the middle of whatever the program happened to be doing. There is no meaningful caller to receive an exception and no sensible place in the source to attribute it to, so CPython refuses to propagate it. Instead the exception is passed to `sys.unraisablehook`, whose default implementation prints a traceback labelled as ignored and returns. Execution continues; no `except` clause anywhere can catch it; the exit status is unchanged. That is a real operational hazard. Cleanup logic that fails inside a finalizer produces stderr noise that no exception-based alerting notices — and if stderr is discarded, produces nothing at all. Overriding `sys.unraisablehook` to route these through the logging pipeline is a cheap, high-value hardening step for a long-running service. ### Two more sharp edges **Resurrection.** A finalizer can store `self` somewhere reachable and bring the object back to life. CPython tolerates it — since the finalization rules were tightened, `__del__` is called at most once per object, so a resurrected object will not be finalized again. **Cost and surprise.** Defining `__del__` changes an object's teardown path for every instance, and inheritance means a subclass that overrides `__del__` without calling up silently loses the parent's cleanup. ### How to see the delay for yourself The cheapest demonstration is to give a class a finalizer that prints, create an instance inside a function, and then compare two runs: one where the function returns normally, and one where the instance is also appended to a module-level list. In the first the message appears as the function returns; in the second it does not appear until shutdown, if at all. Doing the same with an exception — catching one raised while the instance is on the stack and storing it in a variable — shows the same delay for a much less obvious reason, because the stored exception's traceback still holds the frame that holds the instance. ### What to do instead Make release explicit. The object should expose a `close()` (or equivalent) that is idempotent and that the owner calls on a definite path. Then, if you want a net for the case where nobody called it, register `weakref.finalize` rather than writing `__del__`: it runs at most once, it does not sit on the object's own teardown path, it can be cancelled or invoked early, and it also fires at normal interpreter exit for objects that are still alive. `__del__` is still worth writing for one purpose: a warning. Detecting at finalization time that a resource was never closed, and reporting it, turns a silent leak into a visible defect — while the real closing still happens on the explicit path.