Python may coalesce print() into a single write call
Inada Naoki proposes joining print arguments before writing, mainly to stop multithreaded output from interleaving.
Python’s built-in print() currently issues a separate stream write for each argument, each separator, and the trailing newline. Core developer Inada Naoki has proposed combining that output into one write whenever practical.
The main goal is cleaner behavior under concurrency. When two threads print at once, fragments can interleave, so complete messages arrive smashed together or with newlines in the wrong places. Logging libraries already work around this: structlog’s WriteLogger emits each message in a single write, while its PrintLogger inherits print’s piecemeal path, forcing users to know the implementation detail to stay safe in multithreaded code. Short lines, the common case, would also see fewer Python-level calls and less I/O overhead.
The change is not free. Building one combined string costs memory and copying when arguments are large. Error semantics would shift too. Today, if converting a later argument fails, earlier pieces may already have appeared without a final newline. A single write converts first, so the call tends to emit everything or nothing. Several developers called that stronger guarantee preferable; others noted that keeping as much output as possible still helps when a str method crashes during debugging.
IDLE has long felt the multi-write cost when sys.stdout is replaced by a slower sink, and its docs already advise joining strings before printing. Victor Stinner backed a joined write and sketched careful handling if the join itself runs out of memory. Nick Coghlan favored a short PEP not to relitigate the idea but to record the design choices for later reference.
An implementation is in flight. Early numbers show a regression on buffered stdout because today’s text wrapper can avoid some intermediate objects for ASCII pieces; an internal path that accepts a list of strings is under discussion so the stream can stay efficient. Thresholds for very large prints, exact exception behavior, and whether the first landing must include that optimization remain open.