Repository navigation
PyOS_StdioReadline is printing the prompt on stderr #57078
Description
| BPO | 12869 |
|---|---|
| Nosy | @albertz, @vadmium |
| Superseder |
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 = <Date 2016-01-19.02:50:54.156>
created_at = <Date 2011-08-31.14:38:37.918>
labels = ['interpreter-core', 'type-bug']
title = 'PyOS_StdioReadline is printing the prompt on stderr'
updated_at = <Date 2016-01-19.02:50:54.144>
user = 'https://github.com/albertz'bugs.python.org fields:
activity = <Date 2016-01-19.02:50:54.144>
actor = 'martin.panter'
assignee = 'none'
closed = True
closed_date = <Date 2016-01-19.02:50:54.156>
closer = 'martin.panter'
components = ['Interpreter Core']
creation = <Date 2011-08-31.14:38:37.918>
creator = 'Albert.Zeyer'
dependencies = []
files = []
hgrepos = []
issue_num = 12869
keywords = []
message_count = 6.0
messages = ['143256', '196114', '247982', '255077', '255096', '258570']
nosy_count = 3.0
nosy_names = ['Albert.Zeyer', 'martin.panter', 'Drekin']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '1927'
type = 'behavior'
url = 'https://bugs.python.org/issue12869'
versions = ['Python 2.7', 'Python 3.3', 'Python 3.4', 'Python 3.5', 'Python 3.6']
Activity
albertz commentedon Aug 31, 2011
PyOS_StdioReadline from Parser/myreadline.c is printing the prompt on stderr.
I think it should print it on the given parameter sys_stdout. Other readline implementations (like from the readline module) also behave this way.
Even if it really is supposed to write on stderr, it should use the
sys.stderrand not the system stderr.Drekin commentedon Aug 25, 2013
Related stackoverflow question: http://stackoverflow.com/questions/18419787/where-does-pythons-interactive-prompt-output-to .
vadmium commentedon Aug 4, 2015
Results of experimenting on 3.6:
I agree it would probably be more consistent for the interpreter prompt to go to standard output. It looks like stdout is inspected to determine whether Readline will be used, while stderr is not inspected. So it makes sense for the prompt to go to stdout.
However I disagree that it should go to a redirected stream, sys.stderr or sys.stdout, since sys.stdin does not affect input. But see bpo-17620, about redirecting sys.stdin.
vadmium commentedon Nov 22, 2015
Actually bpo-1927 has a simple patch which should change this to stdout. I haven’t tested, the code looks like that patch will not use a redirected sys.stdout, so it would match not using a redirected sys.stdin.
Drekin commentedon Nov 22, 2015
This is not true – the interactive interpreter reads via PyOS_Readline, which may call whatever readline hook is installed.
I think the situation would be much more clear if something like my proposal was implemented (https://mail.python.org/pipermail/python-dev/2015-November/142246.html).
vadmium commentedon Jan 19, 2016
Adam: My experiments were assuming that PyOS_Readline() only ever uses the basic implementation or the Readline library, in order to see if there was any consistency with how Python worked in common situations.
There is actually a test that waits for the interpreter prompt on stderr; see test_cmd_line_script.CmdLineTest.interactive_python(). I realized that changing this would have to be considered carefully, because it could easily break other code as well. It certainly should not be done in a bug fix release.
Anyway I am proposing a patch in bpo-1927 to fix PyOS_StdioReadline(), so closing this as a duplicate.