[Python-ideas] Pythonic buffering in Py3 print() (original) (raw)

Terry Reedy tjreedy at udel.edu
Mon Jan 9 20:59:40 CET 2012

On 1/9/2012 12:52 PM, Guido van Rossum wrote:

This has nothing to do with print or print(). There are no flush() calls implied by print/print() calls, nor should there be(*). print/print() simply calls sys.stdout.write() one or more times, the final call usually being sys.stdout.write('\n') which will trigger a flush() if the file is line-buffered -- but if you use a trailing comma (Python 2) or end=... (Python 3) the last thing written is not '\n' and no flush() will be triggered.

Whether writing \n flushes or not depends on the platform, the Python version and implementation, and the environment (e.g. most platforms automatically turn on line buffering for files known to be associated with a terminal emulator or other interactive device, assuming there's an easy way to tell).

(*) There are plenty of apps that construct their output using many print/print() calls, and for which flushing after each call would be quite unnecessary and potentially cause lots of redundant I/O operations, ultimately slowing down the app.

Thank you for the clarification. I noted on http://bugs.python.org/issue11633 that there should be no code change

Apps that need flushing should call flush().

and that saying something like this in the print doc entry is the only possible change.

-- Terry Jan Reedy

More information about the Python-ideas mailing list