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?)

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.

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.

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.

Logged In: YES 
user_id=35752

This doesn't look like a bug to me.  Can we close it?

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>.