This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Drekin
Recipients Drekin, benjamin.peterson, brett.cannon, eric.araujo, georg.brandl, gvanrossum, ncoghlan, pitrou, steve.dower, tshepang, vstinner
Date 2014-07-31.11:38:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1406806722.36.0.595220864792.issue17620@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2014-07-31 11:38:42Drekinsetrecipients: + Drekin, gvanrossum, brett.cannon, georg.brandl, ncoghlan, pitrou, vstinner, benjamin.peterson, eric.araujo, tshepang, steve.dower
2014-07-31 11:38:42Drekinsetmessageid: <1406806722.36.0.595220864792.issue17620@psf.upfronthosting.co.za>
2014-07-31 11:38:42Drekinlinkissue17620 messages
2014-07-31 11:38:42Drekincreate