Message407978
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. |
|
Date |
User |
Action |
Args |
2021-12-07 22:26:42 | eryksun | set | recipients:
+ eryksun, steven.daprano, martin.panter, Quentin Millardet, iritkatriel |
2021-12-07 22:26:42 | eryksun | set | messageid: <1638916002.01.0.0853059424045.issue33411@roundup.psfhosted.org> |
2021-12-07 22:26:41 | eryksun | link | issue33411 messages |
2021-12-07 22:26:41 | eryksun | create | |
|