In Python, what does `with obj as x` bind to `x`, and which two methods must `obj` define?

### The protocol A *context manager* is any object whose **type** defines two methods: * `__enter__(self)` — runs before the block body. Its **return value** is what the `as` target receives. If there is no `as` clause the return value is simply discarded. * `__exit__(self, exc_type, exc_value, tb)` — runs after the block body, on every exit path. That is the whole contract. There is no base class to inherit from, no registration, no decorator required: a plain class with those two methods is a context manager, which is why `with` works uniformly across locks, files, timers, database transactions and one-off helpers you write in five lines. ### What `with` actually compiles to The language reference gives the equivalent source for `with EXPR as TARGET: BODY`: ```python mgr = (EXPR) enter = type(mgr).__enter__ exit = type(mgr).__exit__ value = enter(mgr) hit_except = False try: TARGET = value BODY except: hit_except = True if not exit(mgr, *sys.exc_info()): raise finally: if not hit_except: exit(mgr, None, None, None) ``` Four things fall straight out of that expansion. **1. `as` binds the return value, not the manager.** `TARGET = value`, where `value` came from `__enter__`. The reason `with` over a file gives you the file, and `with` over a lock gives you `True` rather than the lock, is simply what each `__enter__` chose to return. When you write your own manager and want the `as` target to be the manager, you must write `return self` explicitly; forget it and `__enter__` returns `None`, and the block gets `None` bound to a confident-looking name. **2. The lookup is on the type.** `enter = type(mgr).__enter__` — not `mgr.__enter__`. This is the general rule for special methods in CPython: implicit dunder invocations bypass the instance dictionary. Monkey-patching `obj.__enter__ = something` on one instance has no effect on `with obj:`; you have to patch the class. **3. Both lookups happen *before* the body runs.** An object that defines only `__enter__` fails immediately with a `TypeError` reporting that the object does not support the context manager protocol — you never see a partially executed block. **4. `__exit__` is a `finally`, not an `except`.** It runs on normal completion, on `return`/`break`/`continue` out of the block, and when an exception propagates. It does *not* run if the process dies outright — a hard interpreter exit or a signal that kills the process leaves cleanup undone, which is why `with` protects against exceptions, not against `kill -9`. ### The `as` target is a full assignment target `as` is not restricted to a bare name. It accepts any assignment target, so tuple unpacking works when `__enter__` returns a tuple: ```python with open_pair() as (reader, writer): ... ``` and attribute or subscript targets (`as self.conn`, `as slots[0]`) are legal too, though rarely good style. The unpacking happens *inside* the `try`, which matters: if unpacking raises, `__exit__` still runs. ### Convention: return `self`, or return a handle Two shapes are both idiomatic. Returning `self` lets the block call methods on the manager (`with Timer() as t: ...; t.elapsed`). Returning a *different* object hides the manager entirely and hands the block only the resource it needs — a connection, a cursor, an open handle. Choose deliberately: the second shape means the manager object is unreachable from inside the block, which is usually what you want when the manager exists only to sequence setup and teardown. ### Why interviewers ask this Hand-rolling a context manager is a five-minute whiteboard exercise, and two mistakes are extremely common: omitting `return self` from `__enter__`, and giving `__exit__` the wrong arity. Both are visible in ten seconds of reading, and both reveal whether the candidate has ever written a manager or only used one. ```python class Transaction: def __init__(self, conn): self.conn = conn def __enter__(self): self.conn.begin() return self.conn # the block gets the connection def __exit__(self, exc_type, exc_value, tb): if exc_type is None: self.conn.commit() else: self.conn.rollback() ``` That manager returns nothing truthy from `__exit__`, so any exception continues to propagate after the rollback — the default and usually the correct choice. ### One thing `with` does not do It does not catch anything on your behalf. The construct is a `try/finally`, not a `try/except`: the exception is handed to `__exit__` so cleanup can see it, and unless that method's return value explicitly says otherwise it carries on propagating once teardown is done. A block that must *handle* a failure still needs its own `try/except` around it. The manager guarantees that teardown happens; deciding what a failure means is the caller's policy, and mixing the two into one class is how managers become untestable. That division is the reason the protocol is only two methods long, and it is worth saying out loud when you are asked to hand-roll one.