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.

classification
Title: Py3k's print() flushing problem
Type: behavior Stage:
Components: Build Versions: Python 3.0
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gvanrossum, wojtekwalczak
Priority: high Keywords:

Created on 2007-11-07 18:36 by wojtekwalczak, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg57215 - (view) Author: Wojciech Walczak (wojtekwalczak) * Date: 2007-11-07 18:36
py3k's print() is not flushing when the string's length is 1 byte long 
and 'end' parameter is set to ''. Example:
>>> print('x',end='') # it should print 'x' but it does nothing
>>> print('') # we have to call second print() to get buffers flushed
x
>>>

The same thing happens when the string is empty and end's length is 1:
>>> print('',end='x') # it should print 'x' but it does nothing
>>> print('') # we have to call second print() to get buffers flushed
x
>>>

When there is more characters than one, print() is flushing allright 
(despite of lack of a newline in the interpreter):
>>> print('x',end='y')
xy>>> print('xx',end='')
xx>>> print('',end='yy')
yy>>>
   
The same thing happens in scripts. Try this one as script:
-----------------
import time

print('xx',end='')
time.sleep(3)
print('x',end='')
time.sleep(3)
-----------------

First print() will flush immediately even though there is no newline
and flush is not called, while second print() will flush after second
sleep (because python is flushing buffers at the end of the script).
The conclusion is that print() is not flushing immediately when
string is 1 byte long, but when it is longer - then print() is
flushing even when there is no newline or flush was not called by the 
programmer.

I guess print() should act in the same way for every string > 0 bytes 
long instead of for every string > 1 byte long.

Any ideas where is the bug?

You can find Python-3000's mail list discussion about that bug here: 
http://mail.python.org/pipermail/python-3000/2007-November/011191.html


Wojtek Walczak
msg57255 - (view) Author: Wojciech Walczak (wojtekwalczak) * Date: 2007-11-08 15:09
2007/11/8, admin <report@bugs.python.org>:

> ----------
> keywords: +py3k
> priority:  -> high
> resolution:  -> accepted

Which resolution was accepted?

Wojtek Walczak
msg57284 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-11-09 00:03
I don't think anything was accepted yet.
msg58206 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-12-05 05:47
In r59341 I added a flush of stdout and stderr at the end of each
command that restores the following behavior:

>>> n = sys.stdout.write('X')
X>>> 

I still need to change io.py to properly implement line buffering
though; the current implementation is wrong.
msg58236 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-12-06 01:04
Committed revision 59379.

This adds proper line_buffering behavior.
History
Date User Action Args
2022-04-11 14:56:28adminsetgithub: 45741
2008-01-06 22:29:45adminsetkeywords: - py3k
versions: Python 3.0
2007-12-06 01:04:52gvanrossumsetstatus: open -> closed
resolution: fixed
messages: + msg58236
2007-12-05 05:47:27gvanrossumsetmessages: + msg58206
2007-11-20 10:13:09christian.heimessetassignee: gvanrossum
2007-11-09 00:03:17gvanrossumsetresolution: accepted -> (no value)
messages: + msg57284
nosy: + gvanrossum
2007-11-08 15:09:41wojtekwalczaksetmessages: + msg57255
2007-11-08 15:03:12christian.heimessetpriority: high
keywords: + py3k
resolution: accepted
2007-11-07 18:36:11wojtekwalczakcreate