This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Add flush keyword to print()
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.3
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: Arfrever, cameron, eric.araujo, georg.brandl, giampaolo.rodola, gvanrossum, pitrou, python-dev, techtonik, terry.reedy
Priority: normal Keywords: easy, patch

Created on 2012-01-11 08:24 by georg.brandl, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
flush.patch georg.brandl, 2012-01-11 19:50 review
Messages (14)
msg151041 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-01-11 08:24
Add a flush keyword argument to print(), defaulting to False. If true, output will be flushed immediately.

msg151075 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2012-01-11 18:27
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.
msg151082 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-01-11 19:28
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>.
msg151083 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-01-11 19:38
There is a reason: we don't usually check the type of flag arguments; just their truth value is used.
msg151084 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-01-11 19:50
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()).
msg151091 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2012-01-11 21:14
I'd ignore the failure. It could easily mask some other more interesting error.
msg151104 - (view) Author: Cameron Simpson (cameron) * Date: 2012-01-12 01:12
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.
msg151107 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-01-12 01:51
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)
msg151108 - (view) Author: Cameron Simpson (cameron) * Date: 2012-01-12 02:02
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.
msg151109 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2012-01-12 02:57
Ok, I'm fine with passing through the exception from flush().
msg151119 - (view) Author: anatoly techtonik (techtonik) Date: 2012-01-12 08:24
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.
msg151132 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2012-01-12 15:55
Anatoly, duly noted, and disagreed with.
msg151134 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-01-12 16:08
Patch LGTM.  (s/assertEquals/assertEqual/ though, or you’ll get a warning)
msg151187 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-01-13 18:42
New changeset 3120a988a1a3 by Georg Brandl in branch 'default':
Closes #13761: add a "flush" keyword argument to print().
Date User Action Args
2022-04-11 14:57:25adminsetgithub: 57970
2012-01-13 18:42:17python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg151187

resolution: fixed
stage: needs patch -> resolved
2012-01-12 16:08:27eric.araujosetnosy: + eric.araujo
messages: + msg151134
2012-01-12 15:55:06gvanrossumsetmessages: + msg151132
2012-01-12 08:24:56techtoniksetnosy: + techtonik
messages: + msg151119
2012-01-12 04:04:16Arfreversetnosy: + Arfrever
2012-01-12 02:57:29gvanrossumsetmessages: + msg151109
2012-01-12 02:02:17cameronsetmessages: + msg151108
2012-01-12 01:51:23pitrousetnosy: + pitrou
messages: + msg151107
2012-01-12 01:12:35cameronsetmessages: + msg151104
2012-01-11 23:56:28cameronsetnosy: + cameron
2012-01-11 21:14:27gvanrossumsetmessages: + msg151091
2012-01-11 19:50:17georg.brandlsetfiles: + flush.patch
keywords: + patch
messages: + msg151084
2012-01-11 19:38:57georg.brandlsetmessages: + msg151083
2012-01-11 19:28:07terry.reedysetnosy: + terry.reedy
messages: + msg151082
2012-01-11 18:27:13gvanrossumsetnosy: + gvanrossum
messages: + msg151075
2012-01-11 08:47:31giampaolo.rodolasetnosy: + giampaolo.rodola
2012-01-11 08:24:42georg.brandlcreate