Why can contextlib.suppress cost more than try/except pass in a hot loop?

## The two forms are not equivalent in cost `contextlib.suppress(KeyError)` and `try: ... except KeyError: pass` express the same intent, and people reasonably assume the stdlib helper is free. It is not, and the reason is a nice test of whether you understand what the `with` statement compiles to versus what `try` compiles to on a modern CPython. **`try` entry is free.** Since 3.11 the compiler emits no handler-setup instruction for entering a guarded region; the handler ranges live in a static table on the code object and are consulted only while an exception is propagating. A `try/except` that never catches costs literally nothing at runtime. **`with` entry is not free.** `contextlib.suppress` is an ordinary class. A `with` statement over an instance of it looks up and calls `__enter__` on entry and `__exit__` on exit, unconditionally, on every pass. Both are Python-level functions in the standard library, so each iteration pays two full function calls — frame setup, argument passing, return — before any of your code runs. `__exit__` additionally receives the exception type, value and traceback (all `None` when nothing raised) and performs a class check to decide whether to swallow. On top of that, the usual spelling constructs the manager inline — `with suppress(KeyError):` — so a fresh instance is allocated on every iteration too. ## How big is the difference? Small. Tens of nanoseconds per iteration on a current build: two Python-level calls plus an allocation, against zero. That is irrelevant in almost all code and visible in a loop running millions of times where the body itself is a single dictionary lookup — exactly the situation where a reviewer notices. Measure it with `timeit` rather than asserting it: time both spellings with the same loop count, take the minimum of several repeats, and divide by the count to get nanoseconds per operation. If the gap is smaller than the spread between your repeats, there is nothing to talk about. ## Hoisting the instance `contextlib.suppress` is documented as **reentrant**, which means a single instance may be used in more than one `with` statement, including nested ones, without breaking. So you may legitimately build it once at module level and reuse it in the loop. That removes the per-iteration construction but not the two method calls, so it recovers part of the gap and never all of it. Do not assume this of context managers in general: most are single-use, and reusing one that keeps state is a bug, not an optimization. ## The semantic difference that matters more than the cost If you take one thing from this question, take this: the two forms do not do the same thing. A suppressed exception **exits the entire `with` block**. Statements after the failing one inside the block never run, and control resumes after the block. So this: ```python with suppress(KeyError): total += budgets['svc-1'] seen.add('svc-1') ``` silently skips the `seen.add` when the lookup fails, which is almost never what the author meant. Keeping the block to a single statement is the discipline that makes `suppress` safe, and it is also what makes it read well: one line whose failure you genuinely do not care about. ## When each one is right Reach for `contextlib.suppress` when it improves readability at a place that is not hot: removing a file that may not exist, closing something that may already be closed, one expression whose failure is genuinely uninteresting. It reads as a declaration of intent, and it cannot accidentally grow a handler body that does real work — a `pass` handler can. Use `try/except` when you are in a hot loop, when you want statements after the failure to still run, when the handler needs to do anything at all (log, count, substitute a value), or when you want to bind the exception with `as` and inspect it. `suppress` deliberately gives you no access to the exception it swallowed. ## How to answer this in an interview The strong answer has three beats and refuses to overclaim. First the mechanism: `with` pays two Python-level protocol calls per entry while `try` entry compiles to nothing since 3.11. Then the magnitude: tens of nanoseconds, so it only matters in a measurably hot loop, and here is how I would measure it. Then the redirection: the real reason to choose between them is the block-exit semantics and readability, not the nanoseconds. A candidate who declares `suppress` "slow" and bans it has lost the plot as surely as one who insists a `with` statement is free.