homepage

Add a flush keyword argument to print(), defaulting to False. If true, output will be flushed immediately.
See http://mail.python.org/pipermail/python-ideas/2012-January/013340.html 

In the python-ideas discussion people have argued that flush=False should or could be interpreted as "definitely do not flush" which is unimplementable (the buffer may be full, or the stream may be unbuffered, and there is no way to tell a write() call to skip the flushing if the stream's policy would be to flush). Sticklers have proposed to name the flag "force_flush" to avoid this ambiguity, or to pass None instead of False.
I think that's all being hypercorrect -- first of all, nobody is going to explicitly write flush=False since that is the default, and second of all, who could possibly care about not flushing on a per-call basis? The flag should have a short name and simple semantics. flush=True/False does this: if flush is true, an explicit flush() call is made, if it is false, flush() is not called. What the stream does is its business.

I added a couple of lines to the 3.2, 3.3 print doc in #11633. When a change is made here, they could be updated to something like:
"Output buffering is normally determined by *file*. Use flush=True to force immediate output to a device such as a screen."
Unless there is a good reason, I prefer, unlike the other params, *not* allowing flush=None as a synonym for flush=<the default, ie False>.

There is a reason: we don't usually check the type of flag arguments; just their truth value is used.

Here is a patch.
One open question is whether failure in flush() should be reraised (as implemented in the patch), or ignored (as in input()).

I'd ignore the failure. It could easily mask some other more interesting error.

I'm against ignoring a flush failure. What happened to "errors should never pass silently"? IMO, if we get as far as calling flush and having an exception occur, a "more interesting error" hasn't yet occurred.
I really dislike things that fail silently. If the caller asks print to flush, and the flush fails, the caller's request has not been met. The caller needs to know or incorrect behaviour can ensue.

I think it should be re-raised (or rather, let pass through as in the patch). If you are asking for a flush you want to know why it failed.
(it shouldn't ever fail on "normal" files, anyway)

Flush can fail of disc full or any number of low level things that prevent the OS getting the data into the on-disc file.
Speaking for myself, I certainly want to know if that happens.

Ok, I'm fine with passing through the exception from flush().

I am not discussing "printing to file", so my 0.02 is that "flush=True" should be made default for print() with sys.stdout, because it is probably what users expect when calling this function.
If somebody needs buffering/cache or more fine-grained control over output, they are free to use sys.stdout.write/flush directly.
And users won't be happy to wrap every print() into try/catch to guard from the flush exceptions.

Anatoly, duly noted, and disagreed with.

Patch LGTM. (s/assertEquals/assertEqual/ though, or you’ll get a warning)

New changeset 3120a988a1a3 by Georg Brandl in branch 'default':
Closes #13761: add a "flush" keyword argument to print().
http://hg.python.org/cpython/rev/3120a988a1a3