2

If I want to use the print with the comma (2.6), it works fine as long as you don't use time.sleep().

If you use the print with the comma, and then invoke sleep; the string will never print, if you are in a loop.

Example:

a=1
b=10
while a<b:
    print "yes",
    a=a+1

This works, you will see yes printed on the same line for 10 times. But this won't work.

a=1
b=10
while a<b:
    print "yes",
    time.sleep(1)
    a=a+1

The expectation is that there will be a yes printed; then there is a second of wait, and then the next yes will be printed. Instead, you will see a string of 10 yes printed after 10 seconds.

Same goes if you use while loop; as long as the loop is running, and you have a sleep statement, the string won't print until the end.

To make it work, remove the comma. This makes impossible to print a string on the same line, if you want to specify how long you want to wait between each string.

Is this a bug in the print function?

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140

1 Answers1

5

print does not automatically flush your output. You need to manually do it. This can be done by using sys module's stdout.flush

import sys,time
a=1
b=10
while a<b:
    print "yes",
    sys.stdout.flush()
    time.sleep(1)
    a=a+1

Here is another way to prevent Python from using buffered stdio pipes (Thanks to abarnert)

Execute your program by using the -u option as in

python -u filename.py

From the man pages.

-u
Force stdin, stdout and stderr to be totally unbuffered.

One final way from Python3.3 is to use the flush argument to the print function

Whether output is buffered is usually determined by file, but if the flush keyword argument is true, the stream is forcibly flushed.

Changed in version 3.3: Added the flush keyword argument.

Community
  • 1
  • 1
Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
  • this works....how come that you have to forcefully flush stdout? No newline means no flush? –  Jun 11 '15 at 23:55
  • Nope. It is implemented by the OS designers. The Linix terminal flushes only on newline. For files, it is flushed on file close. – Bhargav Rao Jun 11 '15 at 23:56
  • I see, so this is a limitation of the terminal, not of the language. –  Jun 11 '15 at 23:56
  • 1
    The linux terminal has nothing to do with it at all. The linux _shell_ does, but just barely. The real issue is that stdio pipes are line-buffered by default when interactive, and Python 2 just relies on stdio. Python _could_ set the pipes to unbuffered, or you can even do it from within your own Python program, and neither bash nor your terminal will care. – abarnert Jun 12 '15 at 00:02
  • @abarnert Oops. My bad choice of words. I meant shell when I mentioned terminal. It is mentioned here https://bugs.python.org/issue11633 – Bhargav Rao Jun 12 '15 at 00:03
  • @BhargavRao: But it's really not even up to the shell, it's up to Python (or, in Python 2, up to the platform's stdio implementation). – abarnert Jun 12 '15 at 00:06
  • @abarnert Okay. So the problem is with the Cpython implementation which uses stdio pipes to print? – Bhargav Rao Jun 12 '15 at 00:07
  • @BhargavRao: With Python 2, if you start the interpreter with the `-u` flag, it will open its stdio pipes in unbuffered mode (and binary mode). Is that what you're looking for? – abarnert Jun 12 '15 at 00:07
  • 1
    @BhargavRao: Ultimately, yeah, I guess the fact that Python 3 stopped using stdio means you can say that stdio is the problem. In 3.x, Python uses a stack of adapters on top of raw file descriptors and does its own buffering. But what it does by default is pretty close to what stdio does on POSIX systems, so I think a better way to put this is that there _isn't_ a problem; stdout is line-buffered by default for good reasons. In 3.3, they added a `flush` keyword argument to `print` for when you want "mostly line-buffered, but not this particular `print` call". – abarnert Jun 12 '15 at 00:10
  • @abarnert Thanks. I have added the two other mentioned ways to the answer. Do review it for any mistakes. Thanks again – Bhargav Rao Jun 12 '15 at 00:16
  • 1
    @BhargavRao: It all looks good. I'm not sure you need to mention Python 3.x at all, because everything has changed so much, but it doesn't hurt for some future searcher who has what looks like the same problem because he doesn't know that 2.x and 3.x are different, so sure, why not. – abarnert Jun 12 '15 at 00:36