Eryk Sun added the comment:
> It would be nice to get an unit test for this case.
The process code page from GetACP() is either an ANSI code page or CP_UTF8
(65001). It should never be a Western OEM code page such as 850. In that case,
a reliable unit test would check that the configured
Eryk Sun added the comment:
> The solution here is to fix config_init_stdio_encoding() to use
> GetConsoleCP() and GetConsoleOutputCP() to build a "cpXXX" string.
But, as I mentioned, that's only possible by replacing config->stdio_encoding
with three separate settings:
STINNER Victor added the comment:
> This is based on config_init_stdio_encoding() in Python/initconfig.c, which
> sets config->stdio_encoding via config_get_locale_encoding(). Cannot
> config->stdio_encoding be set to NULL for default behavior?
I would like to get a PyConfig structure fully
Eryk Sun added the comment:
There's a related issue that affects opening duplicated file descriptors and
opening "CON", "CONIN$", and "CONOUT$" in legacy I/O mode, but this case has
always been broken. For Windows, _Py_device_encoding needs to be generalized to
use _get_osfhandle and
New submission from Eryk Sun :
In Python 3.8+, legacy standard I/O mode uses the process code page from GetACP
instead of the correct device encoding from GetConsoleCP and
GetConsoleOutputCP. For example:
C:\>chcp 850
Active code page: 850
C:\>set PYTHONLEGACYWINDOWSSTDIO=1
