In what order does contextlib.ExitStack unwind the cleanups it registered?

`contextlib.ExitStack` exists so that a **variable** number of cleanups can be managed with the same guarantees a `with` statement gives a fixed one. The ordering rule is the heart of the design: **cleanups run in reverse registration order, last in first out.** ## Why it is a stack at all Every registration method pushes exactly one entry onto an internal list: - `enter_context(cm)` calls the manager's `__enter__`, pushes its `__exit__`, and returns whatever `__enter__` returned. - `push(exit)` pushes an `__exit__`-style callable **without** calling `__enter__`. - `callback(fn, *args, **kwargs)` pushes a plain function that will be called with those arguments and never sees exception information. When the `ExitStack` itself is exited - either because the enclosing `with` block ends or because you call `close()` - it pops entries off the end of that list and invokes them. Popping from the end is what makes the order reverse. ## Why reverse order is the only correct order Resources acquired later frequently depend on resources acquired earlier. A cursor is derived from a connection; a temporary file lives inside a temporary directory; a lock is taken after the object it protects has been created. If cleanup ran in registration order, you would tear down the connection while a cursor still referenced it, or remove the directory while a file inside it was still open. Nested `with` statements have always unwound inner-to-outer for the same reason, and `ExitStack` deliberately reproduces that semantics for the dynamic case, so refactoring a nested `with` into a stack does not change behaviour. ```python from contextlib import ExitStack with ExitStack() as stack: for name in ("first", "second", "third"): stack.callback(print, "closing", name) print("body runs") # body runs / closing third / closing second / closing first ``` ## What happens when the block raises If the body raises, the stack still unwinds completely; each registered exit callback that takes exception details receives `(exc_type, exc_value, traceback)`, and callbacks registered with `callback()` are simply called with their bound arguments. Cleanup is not skipped because the block failed - that is the entire point of the construct. ## What happens when a cleanup itself raises Every remaining cleanup still runs. Suppose three callbacks are registered and the middle one raises: the third runs, the middle raises, and the first still runs afterwards. One cleanup error then propagates out of the `with` statement. If the block body had already raised, the original exception is preserved as the `__context__` of the propagating cleanup error, so the traceback shows both - "during handling of the above exception, another exception occurred". Do not rely on more than that: if several cleanups raise, only one error surfaces, so cleanup code that can plausibly fail should log or swallow its own failure rather than letting it mask a sibling's. ## Unwinding early with close() The stack does not have to be used as a `with` block. `ExitStack()` can be created, populated over time, and unwound by calling `close()`. `close()` runs the same reverse-order unwinding and leaves the stack empty, so a second `close()` is a no-op. That is what makes an `ExitStack` usable as a long-lived member of an object: an object that owns a stack can register cleanups in its own setup path and call `stack.close()` in its shutdown path. The flip side is that a long-lived stack **holds strong references** to every callback and to every argument bound into it. A process that keeps one stack for its whole run and registers a cleanup per unit of work - one per digest batch, say - never releases any of them, and memory grows without bound even though each individual resource looks small. The fix is to scope the stack to the unit of work, or to call `close()` at the end of each cycle and start a fresh one. ## The mental model to carry into the interview Think of `ExitStack` as the `with` statement's nesting turned into runtime data. Whatever a chain of nested `with` statements would do - the order of entry, the order of exit, the guarantee that exiting happens on both the success and the failure path - the stack does the same, but with the shape decided while the program runs rather than when it was written.