Python: why is this print automatically flushing to screen without flush()?

Question

I was reading about std.flush() in python. And I found this example a lot.

import sys,time for i in range(10): print i, #sys.stdout.flush() time.sleep(1)

It is often said that it makes a difference with/without the "sys.stdout.flush()". However, when I called this script from command prompt, it didn't make a difference in my case. Both printed numbers to the screen in real time. I used python 2.7.5 in windows.

Why is that happening?

p.s. In another example which printed the output through subprocess.PIPE instead of to the screen directly, I did observe a difference of the buffering.

What am I missing?

There is likely an answer to explain what you're seeing, but... Is there a specific problem you're trying to solve, or is this intellectual curiosity? — dkamins
– dkamins, Commented Nov 24, 2014 at 2:45
Your operating system is ultimately the one that will decide when to flush. Calling flush is simply a way to guarantee that the output buffer is flushed at that particular moment in time, but it may be flushed automatically by the OS even without calling flush explicitly. — tckmn
– tckmn, Commented Nov 24, 2014 at 2:46
@dkamins You caught me.. It's out of curiosity, originally starting from a real problem that I somehow solved but didn't know how. And after some more reading and experimenting, here I am. — enchy
– enchy, Commented Nov 24, 2014 at 3:38
@Doorknob It looks more like an answer than a comment. :) BTW I am quite impressed by your profile. Cheers. — enchy
– enchy, Commented Nov 24, 2014 at 4:41

paxdiablo · Accepted Answer · 2014-11-24 02:56:14Z

Using flush will generally guarantee that flushing is done but assuming the reverse relationship is a logical fallacy, akin to:

Dogs are animals.
This is an animal.
Therefore this is a dog.

In other words, not using flush does not guarantee flushing will not happen.

Interestingly enough, using Python 2.7.8 under Cygwin in Win81, I see the opposite behaviour - everything is batched up until the end. It may be different with Windows-native Python, it may also be different from within IDLE.

Is it up to the OS or the python version then? I use win7. BTW thanks for the analogy. I didn't realize flush()->flush is a one-way logic before.

ivan_pozdeev · Accepted Answer · 2014-11-24 15:49:19Z

See stdio buffering. In brief:

Default Buffering modes:

stdin is always buffered

stderr is always unbuffered

if stdout is a terminal then buffering is automatically set to line buffered, else it is set to buffered

For me, the example you gave prints:

In cmd:

all the numbers upon exit in Cygwin's python
one by one in Win32 python

In mintty:

both all upon exit
both one by one with -u option
sys.stdout.isatty() returns False!

So, it looks like msvcrt's stdout is unbuffered when it points to a terminal. A test with a simple C program shows the same behaviour.

I didn't do anything to disable output buffering mentioned in the link. I was using python 2.7.5 and my streams point to the terminal (is it? I call it from the cmd window).

Collectives™ on Stack Overflow

Python: why is this print automatically flushing to screen without flush()?

2 Answers 2

2 Comments

1 Comment

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

2 Comments

1 Comment

Linked

Related