GeezerVison is showing github.com — Change input() to always prompt to stderr · Issue #46221 · python/cpython
Change input() to always prompt to stderr #46221Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2008-01-24.20:21:17.610>
labels = ['interpreter-core', 'type-bug', '3.11']
title = 'Change input() to always prompt to stderr'
updated_at = <Date 2022-01-17.18:23:32.143>
user = 'https://github.com/smontanaro' bugs.python.org fields:
activity = <Date 2022-01-17.18:23:32.143>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2008-01-24.20:21:17.610>
creator = 'skip.montanaro'
dependencies = []
files = ['27269', '27270', '41246', '41654']
hgrepos = []
issue_num = 1927
keywords = ['patch']
message_count = 26.0
messages = ['61652', '61655', '116936', '154049', '171087', '171088', '177966', '223493', '241693', '246392', '255080', '255779', '255796', '255933', '255955', '258571', '258576', '258578', '259608', '259635', '259636', '259643', '259754', '268543', '410508', '410815']
nosy_count = 13.0
nosy_names = ['terry.reedy', 'jaraco', 'ggenellina', 'ezio.melotti', 'eric.araujo', 'mdomingues', 'martin.panter', 'serhiy.storchaka', 'Drekin', 'Daniel.Gonzalez', 'bhuvan', 'Carvell Scott', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1927'
versions = ['Python 3.11'] Linked PRs
Activitysmontanaro commented on Jan 24, 2008 ContributorAuthor More actions 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:
- Shouldn't the current documentation be corrected to state that raw_input
writes its prompt to standard error?
- 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. ggenellina commented on Jan 24, 2008 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. BreamoreBoy commented on Sep 20, 2010 Any *NIX gurus who can sort this one? merwok commented on Feb 23, 2012 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. mdomingues commented on Sep 24, 2012 mdomingues commented on Sep 24, 2012 Also uploading a patch for the Python3.2 branch. DanielGonzalez commented on Dec 23, 2012 vadmium commented on Jul 20, 2014 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?
bhuvan commented on Apr 21, 2015 For the record, this bug is still open.
The proposed patch is not merged in any of branches.
The prompt for raw_input in all versions, go to stderr. taleinat commented on Jul 7, 2015 See also issue bpo-24402: input() uses sys.__stdout__ instead of sys.stdout for prompt vadmium commented on Nov 22, 2015 The input() implementation is a bit like this:
def input(prompt):
if stdin and stdout are the original file descriptors, and are terminals:
return PyOS_Readline(sys.stdin, sys.stdout, prompt)
else:
sys.stdout.write(prompt) # Writes to stdout
return sys.stdin.readline()
def PyOS_StdioReadline(stdin, stdout, prompt):
'''Default implementation of PyOS_Readline()'''
sys.stderr.write(prompt) # Writes to stderr
return stdin.readline()
def call_readline(stdin, stdout, prompt):
'''Implementation of PyOS_Readline() in the "readline" module'''
rl_instream = stdin
rl_outstream = stdout # Readline writes to stdout
return readline_until_enter_or_signal(prompt)It looks like PyOS_StdioReadline() has always written to stderr. The stdin and stdout parameters of PyOS_Readline() were added later, in revision dc4a0336a2a3.
I think the changes to myreadline.c will also affect the interactive interpreter prompt. But we have bpo-12869 open to change that to stdout, so maybe the change is okay.
Since input() should no longer depend on any instance of stderr, perhaps the check for “lost sys.stderr” should also be removed.
It may be worth applying any changes in myreadline.c to the independent version in pgenmain.c as well, just for consistency. jaraco commented on Dec 2, 2015 +1 to applying this patch. After reviewing this and bpo-12869, I don't see any substantial objections or concerns. The status is "test needed". Is a test really needed? My instinct that simply aligning the implementation with the docs is sufficient. vadmium commented on Dec 2, 2015 “Test needed” is meant to mean someone needs help producing the problem, but people also seem use it to request a refined test case for the test suite.
A test case is always nice, although in this case it is a bit tricky. I can try to knock one up use the existing infrastructure in test_builtin.PtyTests. A similar test case could probably be made for the interactive interpreter (bpo-12869), but might be more involved, and I don’t think there is any existing code to copy from. iritkatriel commented on Jan 17, 2022 johnslavik commented on Apr 14, 2026 StanFromIreland commented on May 16, 2026 jaraco commented on May 18, 2026 @StanFromIreland I don't think closing this long-running issue as a duplicate of a recent draft PR is the right move. There's a lot of context in this issue. Instead, if that PR is the chosen resolution of this issue, it should probably link to this issue. Reacted by Stan Ulbrych and Bartosz Sławecki
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|