How does contextlib.redirect_stdout let a test capture what a function prints?

### The problem A function that calls `print()` has no return value to assert on. Its only observable effect is a write to whatever object the name `sys.stdout` is bound to at the moment `print` runs — `print` looks that name up on every call, it does not cache it. That indirection is the seam, and `contextlib.redirect_stdout` is the stdlib tool that uses it. ### What redirect_stdout actually does `contextlib.redirect_stdout(new_target)` returns a context manager. On `__enter__` it pushes the current value of `sys.stdout` onto an internal stack and assigns `new_target` to `sys.stdout`; on `__exit__` it pops the old value back. Because the restore happens in `__exit__`, it survives an exception inside the block. It is also reentrant — nesting two of them restores in the right order — and reusable, but it is emphatically *not* thread-safe, because `sys.stdout` is one global slot shared by every thread in the interpreter. The target only needs to be a writable text file object. `io.StringIO` is the natural choice: an in-memory text stream with a `getvalue()` method that returns everything written so far, without closing or flushing anything. `contextlib.redirect_stderr` is the identical mechanism for `sys.stderr`. ```python import contextlib import io def render(rows): for label, count in rows: print(f"{label}: {count}") buf = io.StringIO() with contextlib.redirect_stdout(buf): render([("de", 3), ("fr", 5)]) assert buf.getvalue() == "de: 3\nfr: 5\n" ``` Note the trailing newlines: `print` appends `end`, which defaults to `"\n"`. Asserting equality against a string with no trailing newline is the single most common way this test fails on the first run. Either include the newline, or compare `buf.getvalue().splitlines()` against a list of lines, which is more readable and less brittle about the final terminator. ### What it does not capture The redirect happens purely at the Python-name level. Anything that writes to the operating-system file descriptor 1 without going through the `sys.stdout` object is untouched: * A child process. `subprocess.run([...])` with no `stdout=` argument hands the child the inherited descriptor. The child's output appears on your terminal, and the buffer stays empty. To capture it, ask `subprocess` for it (`capture_output=True`, or `stdout=subprocess.PIPE`) and assert on the returned bytes or text. * A C extension or a library that writes directly at the descriptor level. * Anything that captured `sys.stdout` earlier and stored it — a module that did `out = sys.stdout` at import time holds the *original* object, and your redirect will not reach it. Code written as `print(..., file=self.out)` where `self.out` was bound in `__init__` has the same shape. When you genuinely need descriptor-level capture — testing a wrapper around a child process, say — the redirect is the wrong tool: point the child's stream at a real file in a temporary directory, or at a pipe, and read that. ### Isolation and parallelism Because the mechanism mutates a process-global, two tests running concurrently in threads will corrupt each other's captures, and a redirect that leaks (a hand-rolled `sys.stdout = buf` with no restore) poisons the rest of the run — typically showing up as a *different* test producing no output, or as a runner that suddenly prints nothing. Always use the context manager rather than assigning `sys.stdout` yourself; the whole value of `redirect_stdout` over two lines of assignment is the guaranteed restore on the exception path. ### The design point an interviewer is listening for Capturing stdout is a seam of last resort. It tests a side effect on a global, which is exactly the coupling that makes the code hard to test in the first place. Two better shapes, in order of preference: 1. **Return the text.** `def render(rows) -> str` and let the caller print it. The test asserts on a value, no globals involved. 2. **Take the stream as a parameter.** `def render(rows, out=sys.stdout)` — the test passes its own `io.StringIO` directly, with no global mutation, and the code stays honest about the fact that it writes somewhere. Reach for `redirect_stdout` when the function is not yours to change, when you are pinning the behaviour of a CLI entry point before refactoring it, or when the printing genuinely is the feature — a command-line tool's output format, for instance. Saying that out loud is what separates "I know the API" from "I know when to use it".