Drekin added the comment:
I looked to the sourcecode and found the following.
First, the codepath of how interactive loop gets its input follows:
Python/pythonrun.c:PyRun_InteractiveLoopFlags
Python/pythonrun.c:PyRun_InteractiveOneObject
Python/pythonrun.c:PyParser_ASTFromFileObject
Parse/parsetok.c:PyParser_ParseFileObject
Parse/parsetok.c:parsetok
Parse/tokenizer.c:PyTokenizer_Get
Parse/tokenizer.c:tok_get
Parse/tokenizer.c:tok_nextc
Parser/myreadline.c:PyOS_Readline OR Parse/tokenizer.c:decoding_fgets
PyRun_InteractiveOneObject tries to get the input encoding via
sys.stdin.encoding. The encoding
is then passed along and finally stored in a tokenizer object. It is tok_nextc
function that gets
the input. If the prompt is not NULL it gets the data via PyOS_Readline and
uses the encoding to
recode it to UTF-8. This is unfortunate since the encoding, which originates in
sys.stdin.encoding, can have nothing to do with the data returned by
PyOS_Readline. Αlso note
that there is hardcoded stdin argument to PyOS_Readline, but it probably holds
tok->fp == stdin
so it doesn't matter.
If the prompt in tok_nextc is NULL then the data are gotten by decoding_fgets
function, which
either use fp_readl > tok->decoding_readline or
Objects/fileobject.c:Py_UniversalNewlineFgets
depending on tokenizer state. tok->decoding_readline handler may be set to
io.open("isisOOO",
fileno(tok->fp), …) (I have no idea what "isisOOO" might be).
PyOS_Readline function either calls PyOS_StdioReadline or the function pointed
to by
PyOS_ReadlineFunctionPointer which is by default again PyOS_StdioReadline, but
usually is set to
support GNU readline by the code in Modules/readline.c. PyOS_StdioReadline
function uses my_fgets
which calls fgets.
Now what input() function does. input is implemented as
Python/bltinmodule.c:builtin_input. It
tests if we are on tty by comparing sys.stdin.fileno() to fileno(stdin) and
testing isatty. Note
that this may not be enough – if I inslall a custom sys.stdin but let it have
standard fileno
then the test may succeed. If we are tty then PyOS_Readline is used (and again
together with
sys.std*.encoding), if we aren't then Objects/fileobject.c:PyFile_WriteObject >
sys.stdout.write
(for prompt) and :PyFile_GetLine > sys.stdin.readline are used.
As we can see, the API is rather FILE* based. The only places where sys.std*
objects are used are
in one branch of builtin_input, and when getting the encoding used in
tokenizer. Could it be
possible to configure the tokenizer so it uses sys.stdin.readline for input,
and also rewrite
builtin_input to allways use sys.std*? Then it would be
sys.stdin.buffer.raw.read* methods'
responsibility to decide whether to use GNU readline or whatever PyOS_Readline
uses or something
else (e.g. ReadConsoleW on Windows tty), and also check for Ctrl-C afterwards.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17620>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
