classification
Title: raw_input behavior incorrect if readline not enabled
Type: behavior Stage: test needed
Components: Interpreter Core Versions: Python 3.4, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Daniel.Gonzalez, eric.araujo, ezio.melotti, ggenellina, mdomingues, vadmium
Priority: normal Keywords: patch

Created on 2008-01-24 20:21 by skip.montanaro, last changed 2014-07-20 01:35 by vadmium.

Files
File name Uploaded Description Edit
promptOutputFix.patch mdomingues, 2012-09-24 01:21 A proposed patch to print raw_input prompts to standard out. review
promptOutputFix3.patch mdomingues, 2012-09-24 01:26 Fixes the input prompt issue on the Python3 branch. review
Messages (8)
msg61652 - (view) Author: Skip Montanaro (skip.montanaro) * (Python committer) Date: 2008-01-24 20:21
From a thread on python-dev...

http://mail.python.org/pipermail/python-dev/2008-January/076446.html

Mike Kent mike.kent at sage.com
Thu Jan 24 16:33:47 CET 2008

Recently I was trying to debug an old python program who's maintenance I
inherited.  I was using the quick-and-dirty method of putting some 'print
>>sys.stderr' statements in the code, and then running the command with
'2>filename' appended to the end of the command line.  Imagine my surprise
to see that all of the prompt text from the program's raw_input calls were
also disappearing from the screen output, and appearing in the stderr
output routed to the file.

The latest documentation for raw_input states "If the prompt argument is
present, it is written to standard output without a trailing newline."
I posted a question regarding the observed behavior to comp.lang.python
and Gabriel Genellina (thanks Gabriel!) pointed out that despite the
documentation, raw_input was hard-coded to always output its prompt text
to stderr.

This raises two questions:
1. Shouldn't the current documentation be corrected to state that raw_input
writes its prompt to standard error?
2. Is this really the hard-coded behavior we want?  I don't think my
use-case is that odd; in fact, what I find very odd is that the prompt
output is send to stderr.  I mean, I'm printing the prompt for a question,
not some error message. Can there not at least be an optional parameter to
indicate that you want the output sent to stdout rather than stderr?

... after a few responses ...

Guido van Rossum guido at python.org
Thu Jan 24 21:09:12 CET 2008

On Jan 24, 2008 11:41 AM, Mike Kent <mike.kent at sage.com> wrote:
...
> Interesting point about whether GNU readline is installed.  My setup
is RedHat
> Linux, with Python 2.5 that I built and installed myself.  GNU
readline is not,
> in fact, installed.  If you look at Python2.5/Parser/myreadline.c,
function
> PyOS_StdioReadline, line 125, you will see that prompt output is being
sent to
> stderr.  As best as my Python-fu can determine, this is the code used
to output
> a raw_input prompt (thanks again to Gabriel Genellina for pointing me
in the
> right direction.)
>
> It's entirely likely that the difference in what I am seeing and what
you guys
> are seeing is caused by my not having GNU readline installed. 
Nevertheless,
> the behavior without it seems wrong, and is certainly different from the
> documentation.

Agreed.
msg61655 - (view) Author: Gabriel Genellina (ggenellina) Date: 2008-01-24 22:31
GNU readline is configured as to prompt the user using standard output, 
and read input from standard input; if this is the desired behavior it 
would be easy to provide a simple patch so input/raw_input behave that 
way even when readline is not used.
msg116936 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-09-20 13:53
Any *NIX gurus who can sort this one?
msg154049 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-02-23 04:22
From reading the code for raw_input in 2.7 or input in 3.3 (Python/bltinmodule.c:1573), it looks to me that stdout is used, which would mean this issue is fixed.  However I browsed the file history and could not find the commit that changed this, and my C skills are limited, so I’m adding Ezio to nosy to have another pair of eyes confirm.
msg171087 - (view) Author: Michael Domingues (mdomingues) Date: 2012-09-24 01:21
The code that dictates this behavior is in /Parser/myreadline.c and has not been rectified yet in either Python 2.7 (http://hg.python.org/cpython/file/bfdf366a779a/Parser/myreadline.c#l107) or the default branch (http://hg.python.org/cpython/file/c64dec45d46f/Parser/myreadline.c#l111). Specifically, within these functions, references to standard error should actually be references to standard out.

The attached file is a proposed patch for this bug on the 2.7 branch, bringing interpreter behavior into accordance with the Python documentation (http://docs.python.org/library/functions.html#raw_input), which states that the prompt is written to standard out, as opposed to standard error.
msg171088 - (view) Author: Michael Domingues (mdomingues) Date: 2012-09-24 01:26
Also uploading a patch for the Python3.2 branch.
msg177966 - (view) Author: Daniel Gonzalez (Daniel.Gonzalez) Date: 2012-12-23 09:33
Please see this stackoverflow thread where more information is given about this issue:

http://stackoverflow.com/questions/14009714/strange-redirection-effect-with-raw-input
msg223493 - (view) Author: Martin Panter (vadmium) Date: 2014-07-20 01:35
I experimented with various redirections to /dev/null, files, and other terminal windows on Linux. Current behaviour I am seeing seems to be something like this:

* Prefers prompting to stderr if both stdout and stderr are terminals
* Prefers prompting to stdout if neither are terminals
* Prompts to the non-terminal if only one of stderr and stdout is a terminal. Surely this one should be the other way around if there is going to be a preference at all?
History
Date User Action Args
2014-07-20 01:35:18vadmiumsetnosy: + vadmium

messages: + msg223493
versions: + Python 3.4
2014-02-03 19:04:58BreamoreBoysetnosy: - BreamoreBoy
2012-12-23 09:33:18Daniel.Gonzalezsetnosy: + Daniel.Gonzalez
messages: + msg177966
2012-09-24 01:26:28mdominguessetfiles: + promptOutputFix3.patch

messages: + msg171088
2012-09-24 01:21:31mdominguessetfiles: + promptOutputFix.patch

nosy: + mdomingues
messages: + msg171087

keywords: + patch
2012-02-23 04:22:36eric.araujosetnosy: + ezio.melotti, eric.araujo
messages: + msg154049
2010-09-20 13:53:20BreamoreBoysetnosy: + BreamoreBoy

messages: + msg116936
versions: + Python 2.7, - Python 2.6
2010-05-20 20:36:08skip.montanarosetnosy: - skip.montanaro
2010-01-29 04:42:52brian.curtinsetstage: test needed
versions: - Python 2.5
2008-01-24 22:32:00ggenellinasetnosy: + ggenellina
messages: + msg61655
2008-01-24 20:33:44christian.heimessetpriority: normal
2008-01-24 20:21:28skip.montanarosettype: behavior
2008-01-24 20:21:17skip.montanarocreate