What does the flush=True argument to Python's print() do?

## What print() actually touches A call to `print("hello")` never speaks to a terminal or a file directly. It formats its arguments, joins them with `sep`, appends `end` (a newline by default) and calls `write` on a file object — `sys.stdout` unless you passed `file=`. That object is an `io.TextIOWrapper`: a text layer that encodes `str` to bytes and hands them to a binary buffered layer (an `io.BufferedWriter`), which in turn accumulates bytes and eventually issues a real `write` system call on the underlying `io.FileIO`. So there are three layers, and the interesting one for this question is the middle one: bytes pile up in a userspace buffer that belongs to your process, not to the kernel. ## When the buffer is emptied That buffer is drained in only a handful of situations: it fills up; the stream is line-buffered and you wrote a newline; someone calls `sys.stdout.flush()` (which `print(..., flush=True)` does for you); the file object is closed; or the interpreter shuts down normally and flushes and closes the standard streams. Nothing else empties it — not the passage of time, not the reader of the pipe asking for data. Whether newlines flush depends on how the stream was configured at startup. When CPython starts and finds `sys.stdout` attached to a terminal, it makes it line-buffered, so each `print()` ending in `\n` reaches the terminal immediately and `flush=True` changes nothing you can see. When stdout is a pipe or a redirected file, it is block-buffered instead, with a buffer of `io.DEFAULT_BUFFER_SIZE` — 128 KiB on CPython 3.14, up from 8 KiB in older releases. That is a lot of progress lines to accumulate before anything appears, and it is exactly why a script that looked chatty in your shell goes silent under `| grep`, under a supervisor, or inside a container whose logs you are tailing. ## What flush=True does, precisely `flush=True` calls `flush()` on the target file object after the write. The text layer pushes any pending characters down to the binary layer, and the binary layer issues the `write` syscall. After that the data is in the kernel — visible to any other process that reads the pipe or the file — and out of reach of your process crashing. `print()` has accepted the keyword since Python 3.3; the equivalent explicit form is `sys.stdout.write(...)` followed by `sys.stdout.flush()`. ## What it does not do It is not a durability guarantee. Once the kernel has the bytes they are in the page cache, and a machine that loses power can still lose them; forcing them onto the storage device is a separate call and a separate concern. It also does not change how the stream is configured — the next `print()` without the keyword buffers exactly as before. And it does not affect other file objects: a file you opened yourself with `open()` has its own buffer and its own settings. ## The process-wide alternatives When you find yourself adding `flush=True` to every call, switch the stream instead. `python -u script.py` and the `PYTHONUNBUFFERED=1` environment variable both make the standard streams unbuffered — the usual choice for a containerized service, because it needs no code change. `sys.stdout.reconfigure(line_buffering=True)` (available since Python 3.7) turns line buffering back on for a piped stdout, which is cheaper than fully unbuffered output because it still batches within a line. A logging framework is another answer: `logging.StreamHandler` flushes after each record it emits, which is why a service that logs properly shows output promptly while its stray `print()` calls do not. ## Cost, and why it is not the default everywhere Buffering exists because a `write` syscall costs far more than appending to memory. A loop that prints a million short lines with `flush=True` performs a million syscalls; the same loop buffered performs a few dozen. For human-paced progress output the cost is irrelevant and the visibility is worth everything. For high-rate output it is not, and the sane middle ground is to flush on a schedule, or at meaningful checkpoints, rather than on every line. ## The interview point The reason this comes up so often is that the symptom is misleading: no output looks like a hung or crashed program, when in fact the program is running fine and its words are simply parked in memory. Being able to say "stdout is block-buffered because it is not a tty, so add `flush=True`, run with `-u`, or set `PYTHONUNBUFFERED=1`" is a small piece of knowledge that saves hours of misdirected debugging.