Eryk Sun <[email protected]> added the comment:
PyOS_Readline() calls PyOS_StdioReadline() if sys_stdin or sys_stdout isn't a
tty file. This function always writes the prompt to stderr, as follows:
if (prompt) {
fprintf(stderr, "%s", prompt);
}
fflush(stderr);
Maybe this matched the behavior of the readline module and/or GNU Readline in
the past. It's definitely *not* the case in Linux with Python 2.x or 3.x with
readline linked to "libreadline.so.8". In this case, the prompt gets written to
stdout. For example:
$ python -q 2>err.txt
>>> import a
>>> $
$ cat err.txt
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'a'
In Windows, OTOH, the readline module isn't available in the standard library,
in which case PyOS_StdioReadline() is called. For the io._WindowsConsoleIO
update in 3.6, this function was modified to use ReadConsoleW() and
WriteConsoleW() instead of my_fgets(). But I think modifying
PyOS_StdioReadline() was a mistake. The changes should have been implemented as
a new hook for PyOS_ReadlineFunctionPointer. This should have used stdout for
the prompt instead of stderr, normalizing the behavior with interactive
readline on other platforms. Whether or not stderr is redirected to a file or
pipe should make no difference on the behavior.
----------
nosy: +eryksun
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.4, Python
3.5, Python 3.6, Python 3.7, Python 3.8
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue33411>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
