Why choose weakref.finalize over a __del__ method for cleanup in a long-running job?

## The concrete failure that makes people ask A nightly flight-schedule differ runs for about six hours, streaming yesterday's and today's schedules and writing a diff. Each comparison unit opens a scratch file, and each one registers a cleanup so the scratch file goes away when the unit is done with. In staging, where the job processes a few hundred units, everything is tidy. In production, descriptor usage climbs all night and the scratch directory holds tens of thousands of files by morning — and all of them disappear the instant the process exits, so every post-mortem shows a clean disk. The cause was not the finalization mechanism at all: a helper written as `def load(path, cache={})` used a mutable default argument, which is created once at function-definition time and shared by every call, so the cache accumulated parsed schedules — and therefore the units that owned them — for the entire six-hour run. Nothing was collectible, so nothing was finalized until the exit pass. That is the first thing to say about non-deterministic cleanup: **it releases when the object dies, and you often do not control when the object dies.** ## Why finalize is the better of the two automatic mechanisms Given that you want an automatic cleanup at all, `weakref.finalize` beats writing `__del__` on nearly every axis that matters in production. **It is registration, not inheritance.** `__del__` is a class attribute: subclasses inherit it, an override that forgets to call up the MRO silently disables it, and two base classes with their own cleanup collide. A finalizer is attached to one instance at construction time, so composition works. **It cannot resurrect.** `__del__` receives `self` and can store it somewhere, re-animating an object the interpreter had already decided was dead. A finalizer callback never receives the referent, so that whole class of bug is unreachable. **It works on objects you did not write.** You can register a finalizer against a third-party object, or against something whose class you must not modify. There is no equivalent for `__del__` short of subclassing or monkey-patching. **It fires at most once, and you can see it.** `.alive` tells you whether cleanup is still pending; calling the finalizer runs it now; `detach()` cancels it. `__del__` gives you no handle at all. **Its errors are routed, not swallowed.** During the shutdown pass an exception in one callback is passed to `sys.excepthook` and the remaining finalizers still run. ## The shutdown pass, precisely Every finalizer still alive when the interpreter exits is called then, newest first — reverse creation order, on the assumption that later objects may depend on earlier ones. The `weakref` module registers a single hook with the `atexit` machinery the first time any finalizer is created, which produces one behaviour worth knowing: because `atexit` callbacks run last-registered-first, anything you register with `atexit.register` *after* your first finalizer runs *before* all the finalizers, and anything registered before them runs after. Set `.atexit = False` on a finalizer whose cleanup is meaningless during shutdown. ```python import atexit, weakref class Job: pass atexit.register(print, "atexit callback registered first") a = Job(); weakref.finalize(a, print, "finalizer for a") b = Job(); f = weakref.finalize(b, print, "finalizer for b") f.atexit = False ``` ## What neither mechanism buys you Both are best-effort. Neither runs after SIGKILL, `os._exit`, a segfault, or a container being reaped, and neither promises *when* it runs. So the production stance for a six-hour batch job is: 1. **Scope what you can.** `with` blocks and `contextlib.ExitStack` for anything whose lifetime matches a block. That is deterministic and visible in review. 2. **Bound what you cannot.** Cap the number of live units, pool and reuse handles, and do not let a cache silently retain everything the job has touched. 3. **Register a finalizer as the backstop.** It converts "a resource leaked" into "a resource was released later than intended", which is a much better failure. 4. **Clean up out-of-band.** A hard kill leaves scratch files behind no matter what, so the job that creates them needs a sweep on startup, or a directory the platform reclaims. The senior answer to "finalize or `__del__`?" is therefore: prefer `finalize` between the two, and prefer neither as the primary path.