classification
Title: raw_input does not flush stdout
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, jgardn, nascheme, tim.peters
Priority: normal Keywords:

Created on 2002-03-06 13:34 by jgardn, last changed 2002-03-22 19:25 by tim.peters. This issue is now closed.

Messages (6)
msg9537 - (view) Author: Jonathan Gardner (jgardn) Date: 2002-03-06 13:34
I know this has been talked about before. I am curious as to why it has 
not been fixed.

raw_input does not flush stdout before reading from stdin. This is a 
problem because if stdin and stdout are not terminals, then stdout will 
not be flushed, and the "user" will not know when he is being prompted.

Of course, I can use -u at the command line for python, but I don't want 
everything flushed every time stdout is written to. I only want it flushed 
when it is waiting for input. There is the potential for a large amount of 
data to be transmitted, and flushing everything can slow it way down. 
(Imagine 1000's of print statements, all flushing after they are done. 
Silly, isn't it?)




msg9538 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-03-06 13:47
Logged In: YES 
user_id=6380

No reason to get so upset about this. Nobody that I know
uses raw_input() in non-interactive programs. You can help
yourself by using sys.stdin.readline() instead of
raw_input(), and using an explicit sys.stdout.flush() in
your program. If you're not reading interactive input from a
real human user, that's what you should do.

PS. Don't play games with the priority.
msg9539 - (view) Author: Jonathan Gardner (jgardn) Date: 2002-03-06 15:39
Logged In: YES 
user_id=126343

Here's some more info on the subject for those who are interested.

First off, C behaves the way Python does in this regard. So it is consistent with 
the way most programs work in Unix.

Second off, what I really should be doing is using a pseudo-tty, not plain old 
pipes. Tk has something called "expect" that does what you would expect. 
There is a project for expect for python at expectpy - 
http://sf.net/projects/expectpy

Third off, the reason why I got so excited was because I had been screwing 
around with this for a very long time. I knew it was something that was done 
elsewhere in the Unix world, I just didn't know how to do it properly. The 
behavior is totally unexpected for a newbie like me. And when I finally 
climbed through the hole at the top and understood what was happening, I 
was really upset that things were the way they were.

msg9540 - (view) Author: Jonathan Gardner (jgardn) Date: 2002-03-06 15:47
Logged In: YES 
user_id=126343

The reason why they don't use raw_input in non-human interactive programs 
is because it doesn't work like they expect. They usually end up doing 
something like this:

print "Your next command > ",
sys.stdout.flush()
command = sys.stdin.readline() (or something)

Take a look at http://www.freenetpages.co.uk/hp/alan.gauld/tutinput.htm (in 
the yellow box in the middle of the page) for a common idiom with a good 
explanation of why. He is reading interactive input from a non-human user.

PS. I apologize for playing with the priority. I was under the impression that 
bugs/patches just weren't watched. It was more an experiment to see if there 
really was anyone out there paying attention.

msg9541 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2002-03-22 18:37
Logged In: YES 
user_id=35752

This doesn't look like a bug to me.  Can we close it?
msg9542 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-03-22 19:25
Logged In: YES 
user_id=31435

Closing as WontFix.  Until Python implements its own I/O 
(probably never), it inherits C's I/O model, and that's "a 
feature".  All I/O models are subtle, even before Guido was 
born <wink>.
History
Date User Action Args
2002-03-06 13:34:35jgardncreate