Windows sys.stdout codepage / encoding

The documentation on sys.stdout states:

Under Windows, if the stream is interactive (that is, if its isatty() method returns True ), the console codepage is used, otherwise the ANSI code page.

What is “the ANSI code page”? encodings.mbcs “Windows ANSI codepage”?

But testing in practice sys.stdio.encoding is actually cp1252 (if sys.stdio.atty() is False). Is it always cp1252?

What’s the advantage of / reason for switching to a different encoding than the console codepage?
How can other processes detect what encoding must be used? Won’t they typically assume the console codepage?

Thanks.

1 Like

Because there is no console attached sometime. (e.g. pythonw.exe)

Ah, that makes sense, thanks.
But this also happens with python.exe in a console when simply redirecting stdout to a file:
python.exe -c "print('ñ')" >example-file.ext
Or when redirecting stdout to another process:
python.exe -c "print('ñ')" |example-process.exe
Is the console not considered “attached” in these cases either?
What encoding should be expected in file example-file.ext / by process example-process.exe?
I always assumed it was the console codepage.

Sorry for reviving this, just came across this issue too.

python.exe -c "print('ñ')" >example-file.ext

and

python.exe -c "print('ñ')" | example-process.exe

by default will result in CP1252 (coming from import locale; print(locale.getpreferredencoding())), not utf-8.

set PYTHONUTF8=1 or python.exe -Xutf8=1 will change redirected stdout to UTF-8.
It will be default since Python 3.15.

2 Likes