Why is a @contextlib.contextmanager object single-use once its with block has finished?

## One call, one generator `@contextlib.contextmanager` turns a generator function into a factory. Each call to the factory creates a new generator object and a new wrapper around it. A `with` statement drives that generator from its start, through its `yield`, to its end — and a generator, once exhausted, cannot be restarted. So this is a bug: ```python import contextlib @contextlib.contextmanager def phase(label): print("enter", label) try: yield finally: print("exit", label) cm = phase("once") with cm: pass with cm: # boom pass ``` On CPython 3.14 the second `with` raises `AttributeError: '_GeneratorContextManager' object has no attribute 'args'`, because entering deliberately discards the stored factory arguments (they are only needed for recreation, which is no longer possible once the generator has started). Do not memorise that message — memorise the contract. The right answer in an interview is "the object is single-use; call the factory again", and only then, if pressed, "the concrete error is an implementation detail of CPython". ## Single-use, non-reusable, non-reentrant Three distinct properties travel together here, and it is worth separating them. * **Single-use** — the object can be entered once. That is what the example above violates. * **Non-reusable** — you cannot keep a module-level manager object around and use it from several places. `threading.Lock` is reusable; a generator-based manager is not. * **Non-reentrant** — you cannot nest the *same object* inside itself. Even a class-based manager is usually not reentrant unless it was designed to be; the generator form never is. The practical rule that covers all three: **bind the factory to a name, never the manager object.** `with phase("x"):` at each site is correct; `CM = phase("x")` at module level and `with CM:` in three functions is a latent failure that shows up the second time the code path runs — often only under a second request, a second row, or a retry. ## The trap in shared setup The common way to hit this is factoring out "the manager we always use" into a shared object rather than a shared function. Test helpers are the classic host: a module-level `TXN = transaction()` used by several tests works for whichever test runs first and fails for the rest, with an error that points at the standard library rather than at the helper. The fix is one character of indirection — make the helper a callable and call it per use. ## Where reuse genuinely works: the decorator form The object produced by `@contextlib.contextmanager` inherits `contextlib.ContextDecorator`, which means it can be used to decorate a function: ```python import contextlib @contextlib.contextmanager def phase(label): print("enter", label) try: yield finally: print("exit", label) @phase("charge") def charge_customer(): print("working") charge_customer() charge_customer() # works, twice ``` Both calls print their enter/exit pair. That is not reuse of one manager: `ContextDecorator`'s wrapper builds a **fresh** manager for each call of the decorated function, using the arguments the factory was originally given. This is exactly why `__enter__` may discard those arguments — once you have entered the object directly, recreation is off the table, so the decorator path only works from an object that was never entered by hand. The decorator form is the right tool when every call of a function needs the same setup and teardown and the body does not need the yielded value: timing, log context, a feature flag, a temporary directory. If the body needs what the manager yields, keep the explicit `with` inside the function, because the decorator has nowhere to bind an `as` target. ## Choosing the class form instead If you genuinely need one long-lived object that many blocks enter — a connection wrapper, a reusable lock-like guard — write the class with `__enter__` and `__exit__`, where each entry starts from the object's own state rather than from a consumed generator. Reentrancy still has to be designed in (a depth counter, or delegating to a reentrant primitive); a class does not grant it for free. The decision is therefore not "class versus decorator" in the abstract but "how many times will this object be entered": once per acquisition, generator; many times from one object, class. ## Diagnosing it in the wild The signature is an error inside `contextlib` on a `with` line that is obviously fine, appearing on the *second* execution of a path, never the first. Trace the manager expression backwards: if the `with` names a variable rather than a call, you have found it.