Does the `del` statement call an object's `__del__` method in CPython?

### The statement and the method are two different things Python reuses the word `del` for two unrelated mechanisms, and the interview question exists because beginners assume one triggers the other. **`del name` is a namespace operation.** It is the inverse of assignment: it removes the binding from the local, global or class namespace, so that referring to `name` afterwards raises `NameError`. The sibling forms delegate to protocol methods — `del obj.attr` calls `__delattr__`, `del d[key]` calls `__delitem__` — and none of them is guaranteed to destroy anything. Deleting a name is bookkeeping about *labels*, not about *memory*. **`__del__` is a finalizer method.** CPython calls it as part of tearing an object down, right before the object's memory is reclaimed. Nothing in the language says when that moment arrives; the language reference only promises the method is called "when the instance is about to be destroyed". ### What actually schedules the call in CPython CPython's primary memory-management strategy is reference counting. Every live binding — a name, a list slot, a dict value, an attribute of another object, a closure cell, an argument on a live frame — counts as one reference. `del name` drops exactly one: ```python import sys a = object() b = a print(sys.getrefcount(a) - 1) # 2 references (getrefcount adds a temporary one) del a # one reference left; nothing is destroyed ``` Only when the count falls to zero does the deallocation path run, and only then does CPython invoke `__del__`. The call is synchronous and inline: it happens on the thread that dropped the last reference, at the exact statement that dropped it, before the next bytecode executes. That is the property people mistake for determinism — it *is* deterministic, but only with respect to the last reference, and you rarely know where the last reference is. Common reasons the object outlives the `del` you wrote: * another name, a container, or an attribute of a cached object still points at it; * an exception traceback is still reachable, and a traceback keeps every frame — and therefore every local — alive; * the object appears in a reference cycle, so its count never reaches zero on its own. ### Cycles and shutdown: later, or never A cycle (an object referring to itself, or two objects referring to each other) is invisible to reference counting. The cyclic collector finds such groups and, since Python 3.4 (PEP 442), finalizes them properly instead of parking them in `gc.garbage`. So `__del__` still runs — but at whatever moment a collection happens to be triggered, possibly thousands of statements later, possibly during someone else's allocation. And "never" is a real outcome. Objects still alive when the interpreter shuts down are not guaranteed to be finalized; the language documentation states this explicitly. A process that ends through `os._exit`, a signal, or a hard crash skips finalizers entirely, and objects referenced only from a daemon thread stopped at shutdown may simply be abandoned. ### Why this matters more than a trivia point The practical consequence is that `__del__` must never be the only place a scarce resource is released. A file handle, a socket, a database connection or a lock held until "the object is collected" is held for an unbounded time, and under an alternative Python implementation with a tracing collector rather than reference counting it may be held far longer still — the same code that looks tidy on CPython leaks descriptors elsewhere. The idiom to reach for instead is deterministic: a `with` block, or an explicit `close()` in a `try`/`finally`. A finalizer is reasonable as a safety net that logs a warning when someone forgot to close, and unreasonable as the primary mechanism. ```python class Session: def close(self): self.open = False def __del__(self): if getattr(self, "open", False): print("warning: Session was never closed") ``` ### What to say in the room "`del x` unbinds a name and drops one reference. `__del__` runs when the *last* reference goes away — immediately if that was the last one, later if a cycle is involved, and possibly never at interpreter exit. So I use it as a warning net, and put real cleanup in a context manager."