Steve Dower added the comment: > looks like only way to specify console's codepage is with `encoding=os.device_encoding(2)` which will have to be used for 99% of cases
That's true, but it only applies when the subprocess is using the same call (GetConsoleCP) to determine what encoding to use to write to something *other* than the console, which is incorrect. The defaults in this cause ought to be ACP, but it depends entirely on the target application and there is no good "99%" default. To see this demonstrated, check the difference between these two commands (with 3.5 or earlier): python -c "import sys; print(sys.stdin.encoding)" python -c "import sys; print(sys.stdin.encoding)" < textfile.txt When stdin is redirected, the default encoding is not the console encoding (unless it happens to match your ACP). And ACP is not the correct encoding for a file anyway - it just happens to be the default for TextIOWrapper - so to do it properly you need to detect that it's not a console (sys.stdin.isatty()) and then use the raw stream rather than the default wrapper. (Or you specify that your program requires ACP files, or that PYTHONIOENCODING should be set, or that it requires any other encoding and you explicitly switch to that one.) In short, character encoding is hard, and the only way to get it right is for the developer to be aware of it. No good defaults exist. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6135> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
