[Python-bugs-list] [ python-Bugs-526382 ] raw_input does not flush stdout
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 22 Mar 2002 10:37:07 -0800
Bugs item #526382, was opened at 2002-03-06 13:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526382&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input does not flush stdout
Initial Comment:
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?)
----------------------------------------------------------------------
>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 18:37
Message:
Logged In: YES
user_id=35752
This doesn't look like a bug to me. Can we close it?
----------------------------------------------------------------------
Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 15:47
Message:
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.
----------------------------------------------------------------------
Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 15:39
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 13:47
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526382&group_id=5470