Why does re-entering the same context-manager object nested break it, and what makes one reentrant?

### Three properties people conflate For a context-manager object, three different questions have three different answers: * **Reusable** — can this object be entered again *after* a previous `with` block on it has finished? * **Reentrant** — can this object be entered again *while* it is still active, i.e. nested inside its own block, or re-entered by a function the block calls? * **Thread-safe** — can two threads be inside blocks on the same object at once? They are independent. Reentrancy implies reusability in practice, but not the reverse, and neither implies thread safety. The `with` protocol itself says nothing about any of them: `__enter__` and `__exit__` are just methods, and calling them again is not an error the language will catch for you. ### The failure mode, concretely The classic broken shape stores the previous state in one attribute: ```python class Depth: def __init__(self): self.level = 0 def __enter__(self): self._saved = self.level # one slot for all entries self.level += 1 return self def __exit__(self, exc_type, exc_value, tb): self.level = self._saved ``` Enter it once: `_saved = 0`, `level = 1`. Enter the *same object* again inside that block: `_saved` is overwritten with `1`, `level = 2`. The inner exit restores `level = 1` — correct so far. The outer exit then restores `level = _saved`, which is still `1`. The counter never returns to zero. Nothing raised, nothing logged; the object is simply wrong from then on. That is the shape of every save/restore manager: a temporarily swapped global, a redirected output stream, a pushed logging context, a set-and-restore configuration flag. Each one is broken under nesting if the saved value lives in a single attribute. ### Why it shows up in production and not in tests The nesting is rarely visible in one function. Consider a genome-annotation pipeline with a stage manager that opens a transaction and, on failure, performs a partial-failure rollback of the records that stage wrote. A unit test enters it once. In production a stage handler calls a shared helper that — quite reasonably — wraps its own work in the *same* manager instance pulled from module state. Now the manager is nested against itself, and the rollback boundary is wrong: the outer exit restores state the inner exit already restored, so a failure rolls back too little or too much. At a 1,200-request-per-minute peak that surfaces as a small, steady rate of half-written annotation batches with no error in the logs — the worst class of bug to diagnose, because every individual code path reads correctly. ### Making it reentrant: keep a stack The general fix is to make the per-entry state actually per-entry: ```python class Depth: def __init__(self): self.level = 0 self._stack = [] def __enter__(self): self._stack.append(self.level) self.level += 1 return self def __exit__(self, exc_type, exc_value, tb): self.level = self._stack.pop() ``` Entries push, exits pop, and because `with` guarantees a matching `__exit__` for every completed `__enter__`, the stack stays balanced even when the block raises. This is the same idea a reentrant lock uses — count the entries, only really release on the outermost exit. ### Making it reentrant: hand out a token The other fix removes shared mutable state from the manager entirely. `__enter__` returns a fresh object that owns the entry's state, and the manager holds nothing per-entry: ```python class Scope: def __init__(self, registry): self.registry = registry def __enter__(self): entry = {"records": []} self.registry.append(entry) return entry def __exit__(self, exc_type, exc_value, tb): entry = self.registry.pop() if exc_type is not None: entry["records"].clear() ``` Or, more simply still: make the thing you `with` a *fresh object each time* — `with make_scope() as s:` rather than `with SHARED_SCOPE as s:`. A manager that is constructed at the point of use cannot be nested against itself, which is why factory-style managers dominate in practice and why the bug is mostly seen with module-level singletons. ### Threads are the same bug, one level up A stack fixes nesting within one thread and does nothing for two threads sharing the object — both push and pop the same list, and the values interleave. If a manager must be shared across threads *and* nested, the per-entry state belongs in thread-local storage, or the object should not be shared at all. Stating that boundary explicitly is what separates a senior answer from a correct-but-narrow one. ### What to say in an interview Name the three properties, show the single-attribute failure, give the stack fix in four lines, and then say what you would actually do: prefer factory-constructed managers, and document reentrancy and reusability in the class docstring when the manager is a shared object. Silence about those properties in a shared manager is a design defect, not a documentation nit.