ExitStack vs Nested with Resources: Localhost Lab

Intro — what this post promises

Manage N context-managed resources via contextlib.ExitStack vs fixed nested with vs manual try/finally close. This lab reports cycles/s on Linux localhost.

Related links:

• itertools batched vs chunk localhost lab
• graphlib topo vs manual localhost lab
• functools cache vs lru localhost lab
• tomllib vs json localhost lab
• path glob vs fnmatch localhost lab
• dataclass replace vs manual localhost lab
• zoneinfo vs utc offset localhost lab
• heapq merge vs sorted localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. Dummy resources + TemporaryFile. Differentiates from lab 60 — this is dynamic N.

Verdict up front (N=4): manual close ~1056421 cycles/s; nested with ~959372; ExitStack ~253269. At N=64, ExitStack ~20877 vs manual ~58776.

Arms

Lab topology

N in {4, 16, 64} · 500 cycles · 7 rounds · p50
metric: cycles/s = INNER / p50_s

Script: lab-evidence/121-exitstack-vs-nested-with/results/run_lab.py.

Lead table — dummy resources (p50 cycles/s)

Temp files (FD reality)

OS file costs dominate — ExitStack overhead shrinks relatively.

Dynamic N story

You cannot write a statically nested with for len(files) known only at runtime. ExitStack exists for that: push contexts as you open, unwind safely on error.

LIFO cleanup

Resources exit in reverse enter order — same as nested with. Register releases immediately after successful acquire.

Reading it

• Variable resource counts → ExitStack.
• Fixed tiny N → nested with is fine and faster here.
• Manual close is fast but easy to leak under exceptions.
• Not a substitute for structured concurrency task groups.

Exception paths

The win for ExitStack is not the happy-path cycles/s table — it is cleaning up when the 7th of 16 opens fails. Manual lists need careful finally; nested with cannot express variable depth. ExitStack keeps LIFO semantics without a hand-built stack.

Callbacks vs enter_context

callback(close) does not enter a context manager’s __enter__. Prefer enter_context for real CM objects; use callbacks for plain close functions or logging. Mixing both is fine when documented.

FD-bound workloads

TemporaryFile arms show kernel work dwarfing ExitStack bookkeeping (thousands of cycles/s, not hundreds of thousands). Optimize FD count and directory placement before micro-tuning ExitStack vs manual close.

Pitfalls

• Forgetting enter_context / inconsistent callbacks.
• Nesting ExitStacks without need.
• Comparing to lab 60 without dynamic-N framing.
• Blaming ExitStack when TemporaryFile I/O dominates.

Reproduce

python3 lab-evidence/121-exitstack-vs-nested-with/results/run_lab.py

Evidence: summary.json, summary.txt.

Pair ExitStack with typed helpers (open_all(paths)) so call sites stay short and acquire/release policy stays in one module.

Limits

One Linux box. Synthetic DummyResource + local TemporaryFile. Not thread pools.

Keep the comparison honest: measure your resource type (dummy vs FD) before optimizing.

Takeaway

For N=4, nested/manual ~1056421 cycles/s beat ExitStack ~253269. Prefer ExitStack when N is dynamic — correctness under exceptions beats a fixed-with microbench.