Message278394
From memory, there are at least three code paths for input():
1. Fallback implementation, used when stdout is a pipe or other non-terminal
2. Default PyOS_ReadlineFunctionPointer() hook, used when stdout is a terminal: https://docs.python.org/3.5/c-api/veryhigh.html#c.PyOS_ReadlineFunctionPointer
3. Gnu Readline (or another hook installed by a C module)
Arnon’s problem only seems to occur in the last two cases, when PyOS_ReadlineFunctionPointer() is used. The problem is that PyOS_ReadlineFunctionPointer() uses C <stdio.h> FILE pointers, not Python file objects. Python calls sys.stdout.fileno() to see if it can substitute the C-level stdout FILE object.
Adam: I think your sys.readlinehook() proposal is independent of Arnon’s problem. We would still need some logic to decide what to pass to libraries like Gnu Readline that want a FILE pointer instead of a Python file object.
The fileno() method is documented all file objects, including text files like sys.stdout. So I think implementing your own fileno() method is completely valid.
One other idea that comes to mind is if Python checked if the sys.stdout object has been changed (e.g. sys.stdout != sys.__stdout__), rather than just comparing fileno() values. But I am not sure if this change is worth it.
BTW if I revert the fix for Issue 24402 (I also tried 3.3.3), the problem occurs even when a custom fileno() is defined. On the other hand, Python 2’s raw_input() is not affected, presumably because it uses PyFile_AsFile() and fails immediately if stdout is a custom class. |
|
Date |
User |
Action |
Args |
2016-10-09 23:57:14 | martin.panter | set | recipients:
+ martin.panter, wiggin15, Drekin |
2016-10-09 23:57:14 | martin.panter | set | messageid: <1476057434.06.0.330973105076.issue28373@psf.upfronthosting.co.za> |
2016-10-09 23:57:14 | martin.panter | link | issue28373 messages |
2016-10-09 23:57:13 | martin.panter | create | |
|