In CPython, what does `del x` actually do — does it free the object?

## Names, objects and the counter Every CPython object lives on the heap behind a header that carries, among other things, a **reference count**: how many references currently point at it. A *name* is not the object — it is an entry in a namespace (a function's fast-locals array, a module's global dict, a class body's dict) that holds one reference. Binding `x = obj` adds a reference and increments the count; rebinding or removing that entry drops one and decrements it. `del x` is exactly the second half of that: **it removes the binding and decrements the count by one.** That is all the statement does to the object. It does not call `free()`, it does not call `__del__`, and it does not "run the garbage collector". After the statement the name is gone, so touching it raises an error — `NameError` at module or class level, `UnboundLocalError` inside a function, where the compiler has already decided the name is local and cleared its slot. ## When memory is actually released Deallocation is a consequence, not a synonym. When a decref takes the count to **zero**, CPython immediately invokes the type's deallocator, which: 1. runs `__del__` if the type defines one, 2. decrefs everything the object referred to (its attributes, its list items, its closure cells) — which can cascade into a whole tree of frees, 3. returns the memory block to the allocator. All of that happens synchronously, inside the very instruction that dropped the last reference. This is the "deterministic destruction" people mean when they say Python cleans up promptly. The corollary is the interview point: **`del` frees the object only if it removed the last reference.** ```python a = [1, 2, 3] box = {"payload": a} del a # count goes 2 -> 1: the dict still holds the list print(box["payload"]) # the list is very much alive ``` Everything that counts as a reference keeps the object up: another name, an element of a list, tuple or set, a dict value *or key*, an instance or class attribute, a default argument value, a closure cell, an argument sitting in a live call frame, a module-level cache, and the locals of any frame captured by an exception traceback. ## `del` has three different jobs The statement is overloaded, and the target decides which protocol runs: * `del x` — unbind a name in a namespace. * `del obj.attr` — call `type(obj).__delattr__`, which normally removes the entry from the instance `__dict__`. * `del seq[i]` or `del seq[2:5]` — call `type(seq).__delitem__`. The last two remove a *container's* reference, which is often precisely what a leak fix needs: the name was never the problem, the cache entry was. ## `del x` versus `x = None` Both drop one reference. The difference is the binding: after `x = None` the name still exists and now refers to `None`; after `del x` the name is gone. In a long function, rebinding a huge intermediate to `None` before the next allocation and deleting it are equally effective at releasing memory — the choice is about whether later code expects the name to exist. ## The parts `del` does not control Two honest caveats belong in the answer: * Prompt destruction at zero is **CPython's implementation**, not a promise of the language. An implementation with a tracing collector finalizes whenever it likes, so resource cleanup should ride on `with`/`try`/`finally`, never on a well-timed `del`. * If the object participates in a reference cycle, no single decref reaches zero and the object waits for the cycle collector instead — which is why `__del__` should never be treated as a destructor with guaranteed timing. One convenience worth knowing: an `except SomeError as e:` clause **deletes `e` automatically** at the end of the block (Python 3 behaviour, PEP 3110), precisely so the exception and the frames its traceback pins do not outlive the handler. That is the interpreter reaching for the same `del` you would have written by hand. ## What good use looks like `del` earns its place in three narrow situations: releasing a large intermediate inside a long loop before the next allocation, dropping the reference that a test needs gone to assert cleanup happened, and deleting a cache entry through `__delitem__`. Sprinkling `del` at the end of functions is noise — the frame's locals are released when the frame dies anyway.