Repository navigation
Document that print may need explicit flushing #55842
Description
| BPO | 11633 |
|---|---|
| Nosy | @birkenfeld, @terryjreedy, @amauryfa, @vstinner, @cameron-simpson, @merwok |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2012-01-11.19:15:16.176>
created_at = <Date 2011-03-22.10:37:22.403>
labels = ['type-feature', 'docs']
title = 'Document that print may need explicit flushing'
updated_at = <Date 2012-01-14.05:07:41.269>
user = 'https://bugs.python.org/techtonik'bugs.python.org fields:
activity = <Date 2012-01-14.05:07:41.269>
actor = 'python-dev'
assignee = 'docs@python'
closed = True
closed_date = <Date 2012-01-11.19:15:16.176>
closer = 'python-dev'
components = ['Documentation']
creation = <Date 2011-03-22.10:37:22.403>
creator = 'techtonik'
dependencies = []
files = ['21333', '21334', '21349']
hgrepos = []
issue_num = 11633
keywords = []
message_count = 27.0
messages = ['131736', '131737', '131738', '131739', '131741', '131742', '131743', '131755', '131800', '131808', '131811', '131859', '131909', '150924', '150930', '150932', '150955', '150961', '150971', '151080', '151081', '151140', '151149', '151212', '151213', '151223', '151227']
nosy_count = 9.0
nosy_names = ['georg.brandl', 'terry.reedy', 'amaury.forgeotdarc', 'vstinner', 'techtonik', 'cameron', 'eric.araujo', 'docs@python', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue11633'
versions = ['Python 3.2', 'Python 3.3']
Activity
techtonik commentedon Mar 22, 2011
print() function for some reason buffers output on Windows if end!='\n'.
In attached examples "Processing.. " string is shown in Python 3.2 only after the actual processing is finished, while in Python 2.6 it is shown before.
vstinner commentedon Mar 22, 2011
printtest2.py displays directly "Processing.. " on Windows, but not on Linux. It looks like stdout is not buffered on Windows, which looks like a bug to bug :-) I think that it is safer to always call sys.stdout.flush() to ensure that your message is directly displayed. With Python 2, you can use -u flag (unbuffered output) to avoid the explicit flush, but this is very inefficient (slow).
Python 3 uses line buffers, even with python3 -u, for better performances. If you want to see directly "Processing.. ", as Python 2, call sys.stdout.flush().
It is not a regression, it is a choice to be efficient.
techtonik commentedon Mar 22, 2011
From my perspective it is a regression on Windows and a bug in Linux version of Python 2.x, which unfortunately can not be fixed, because of 2.x release process.
If the fact that print statement doesn't output anything when called is not a bug - then should be documented long ago.
vstinner commentedon Mar 22, 2011
Line buffering is used by default on most operating systems (ok, maybe not Windows, which looks strange to me) and is not specific to Python.
Yes, Python has subtle differences on different operating systems, but at least it looks like Python 3 has the same behaviour on Linux and Windows ;-)
Can you please write a patch for the doc? Reopen the issue if you have a patch.
techtonik commentedon Mar 22, 2011
How about making print() user-friendly with flushing after every call, and if you want explicitly want speed - use buffered sys.stdout.write/flush()?
vstinner commentedon Mar 22, 2011
This is exactly the -u option of Python 2: use it if you would like a completly unbuffered sys.stdout in a portable way.
In Python 3, it is only useful to flush at each line, even if the output is not a console, but a pipe (e.g. output redirected to a file). But nobody asked yet to have a fully unbuffered sys.stdout in Python 3.
techtonik commentedon Mar 22, 2011
You must realize that the most common use case for print(..., end!='\n') is when you want to notify user about intermediate progress of a very long operation.
Making documentation for simple print() statement overloaded with low level buffering details makes language seem overly complicated for new users.
amauryfa commentedon Mar 22, 2011
We are talking about different things here:
When python is run from a console, sys.stdout is line buffered. sys.stdout.write() flushes if there is a carriage return. No need to change anything here.
print() could call file.flush() if file.isatty(), *after* the multiple calls to file.write().
terryjreedy commentedon Mar 22, 2011
Python 3.2, WinXP, IDLE edit window, F5 Run:
'Processing ...' appears immediately, 'Done' 3 sec later.
The only difference between printtest2/3 is where 'Done' appears.
Behavior is same when pasting into interactive interpreter -- has to be since the first two prints are executed before the sleep. I presume interpreter flushes before or after printing next prompt. IDLE must do same even when running from editor even when not printing prompts.
Anatoly, I gather you ran files by some other method.
I disagree with closing this yet. Print was designed to be a simplified wrapper around sys.stdout.write (and now, any file.write). Requiring that one import sys to use print goes against that.
I have always experienced and expected Python's print to screen to be immediately visible. I thought that was pretty standard in other languages with a print-to-screen separate from general file-write. When printing to screen, efficiency is, I believe, a non-issue. Writing to files or the net is a whole different ballgame.
Amaury's idea of checking isatty seems good. Otherwise, print should gain an optional, no-default flush=True/False parameter (no default because behavior currently varies.) Until then, non-flushing *should* be documented. The current doc for print does not seem to address the issue either way.
Amaury, I though 'run from console' more or less meant 'isatty', so I am not sure I understand your comment.
16 remaining items
terryjreedy commentedon Jan 9, 2012
The current doc says
"print([object, ...], *, sep=' ', end='\n', file=sys.stdout)
Print object(s) to the stream file, separated by sep and followed by end. sep, end and file, if present, must be given as keyword arguments.
All non-keyword arguments are converted to strings like str() does and written to the stream, separated by sep and followed by end. Both sep and end must be strings; they can also be None, which means to use the default values. If no object is given, print() will just write end.
The file argument must be an object with a write(string) method; if it is not present or None, sys.stdout will be used."
(The bit about None, said twice, could be factored out and said once after the second sentence.)
This is exactly what print does and Guido today (Python ideas) said that is what it should do and that "Apps that need flushing should call flush()." So a code change is rejected.
The issue title was incorrect. The print function does not do any buffering. The file object it writes to may. Even sys.stdout may or may not.
We could add at the end a sentence or two something like
"Output buffering is determined by *file*. Call file.flush() to ensure, for instance, immediate appearance on a screen."
[-]Document that print buffers output when end=''[/-][+]Document that print may need explicit flushing[/+]python-dev commentedon Jan 11, 2012
New changeset bc043cef94f2 by Terry Jan Reedy in branch '3.2':
Closes bpo-11633 Clarify print buffering.
http://hg.python.org/cpython/rev/bc043cef94f2
New changeset fb0d61fd1753 by Terry Jan Reedy in branch 'default':
Merge with 3.2
http://hg.python.org/cpython/rev/fb0d61fd1753
terryjreedy commentedon Jan 11, 2012
bpo-13761 proposes to add flush=False param with option for True.
merwok commentedon Jan 12, 2012
I agree with the python-ideas message that
sys.stdout.flush()is surprising / possibly misleading and should befile.flush(). If the other bug report about adding a flush argument is rejected, please consider this. Thanks :)python-dev commentedon Jan 12, 2012
New changeset 4a767054551b by Terry Jan Reedy in branch '3.2':
bpo-11633 At least 2 people prefer earlier revision.
http://hg.python.org/cpython/rev/4a767054551b
New changeset 22688f5f9d0f by Terry Jan Reedy in branch 'default':
Merge bpo-11633 At least 2 people prefer earlier revision.
http://hg.python.org/cpython/rev/22688f5f9d0f
merwok commentedon Jan 14, 2012
Thank you sir. Should the doc edit be backported to the 2.7 docs, with a mention that it’s only on unix?
cameron-simpson commentedon Jan 14, 2012
Putting the wording into 2.7 might be nice, but I thought it was in bugfix only mode.
Regarding UNIX only, I'd avoid it; any file may be buffered in almost any way on any platform. Saying an explicit flush call may be necessary for immediate output is _not_ UNIX only and would be very misleading. Remembering that ~UNIX != Windows.
Telling users to explicitly call flush to ensure immediate output where that is necessary ensures portable coding (or ought to, user pigheadedness discounted:-)
merwok commentedon Jan 14, 2012
Bug fixes include doc improvements, so 2.7 is fair game.
Thanks for your suggestion to not mention specific platforms. Let’s just backport the 3.2 text.
python-dev commentedon Jan 14, 2012
New changeset 8935a33773b9 by Terry Jan Reedy in branch '2.7':
bpo-11633 about buffering of print
http://hg.python.org/cpython/rev/8935a33773b9