
I would expect that all standard IO in Python goes through sys.stdin, sys.stdout and sys.stderr or the underlying buffer or raw objects. The only exception should be error messages before the sys.std* objects are initialized. I was surprised that this is actually not the case – reading input in the interactive loop actually doesn't use sys.stdin (see http://bugs.python.org/issue17620). However it uses its encoding, which doesn't make sense. My knowledge of the actual implementation is rather poor, but I got impression that the codepath of getting input from user in interactive loop is complicated. I would think that it consits just of wrapping an underlying system call (or GNU readline or anything) in sys.stdin.buffer.raw.readinto or something. With current implementation, fixing issues may be complicated – for example handling SIGINT produced by Ctrl-C on Windows issues. There is a closed issue http://bugs.python.org/issue17619 but also an open issue http://bugs.python.org/issue18597. There is also a seven years old issue http://bugs.python.org/issue1602 regarding Unicode support on Windows console. Even if the issue isn't fixed, anyone could just write their own sys.std* objects a install them in the running interpreter. This doesn't work now because of the problem described. I just wanted to bring up the idea of redesign the stdio backend which also results in fixing http://bugs.python.org/issue17620 and helping fixing the others. Regards, Drekin
participants (1)
-
drekin