Can someone explain this unexpected raw_input behavior?

[Gabriel Genellina]

En Thu, 24 Jan 2008 01:00:53 -0200, Mike Kent <mrmakent at cox.net> escribió:

> Gabriel, thank you for clarifying the source of this behavior.  Still,
> I'm surprised it would be hard-coded into Python.  Consider an
> interactive program, that asks the user several questions, and
> displays paragraphs of information based on those questions.  The
> paragraphs are output using print, and the questions are asked via
> raw_input. You want to do some simple debugging of the program by
> printing some debugging statements via 'print >>sys.stderr', and you
> don't want the debug output mixed in with the normal output on the
> screen, so you try to route the debugging output to a file by adding
> '2>filename' to the end of the command line.
>
> Unfortunately, you will no longer see any of the questions being
> printed via raw_input.  The rest of the output will be fine, but the
> questions disappear.  Your program just stops, without asking
> anything... you have to guess what should be there.

You have one console, two streams to output data (stdout and stderr), and  
three data sources (program output, user prompt, and debugging messages).  
Someone has to give.
I'm now convinced that the current behavior is rather reasonable...

> I'm surprised that Python hard-codes this behavior without giving the
> programmer any way to change it.  It leaves me with two options: to
> either always use the logging module for debugging messages (which is
> not odious at all, it's just that the code in question predates the
> logging module, which is why debugging was done as it is), or change
> the program so that raw_input is never used with a prompt parameter;
> the prompt must always be printed separately.

Perhaps raw_input could have a use_stderr=True parameter; with False would  
display the prompt on stdout.

-- 
Gabriel Genellina