Remove console encoding support from TextIOWrapper.

[methane]

Currently, TextIOWrapper.__init__ calls os.device_encoding(file.fileno()) when encoding is not specified and fileno is 0-2 (e.g. open(0)).

However, sys.stdin, stdout, and stderr don't use it even when PYTHONLEGACYWINDOWSSTDIO=1.
config->stdio_encoding is initialized by GetACP(), and create_stdio() passes config->stdio_encoding to TextIOWrapper.

How about removing os.device_encoding(file.fileno()) from TextIOWrapper.__init__()?

• Thanks to WindowsConsoleIO, most user don't use the console encoding at all.
• WindowsConsoleIO require UTF-8. So TextIOWrapper(sys.stdout) cause mojibake when sys.stdout is WindowsConsoleIO
• The only use case of PYTHONLEGACYWINDOWSSTDIO I know is this. But this use case don't create TextIOWrapper for fd=0,1,2.
• This TextIOWrapper behavior is never documented. It makes TextIOWrapper.__init__ complicated and inconsistent.
• If we want to use console encoding for stdio when PYTHONLEGACYWINDOWSSTDIO is set, we can fix it in create_stdio(). create_stdio() has special case for WindowsConsoleIO already. (here)

Ping: @vstinner @eryksun @zooba

[zooba]

Shouldn't TextIOWrapper take the encoding from the underlying stream if it has a .encoding attribute? That will handle the WindowsConsoleIO case.

What happens if you just call TextIOWrapper(0) (or whichever number is stdout)? I've definitely seen that pattern used occasionally, though I can't remember whether it was meant to be portable or not.

[methane]

What file except WindowsConsoleIO has .encoding attribute?

[zooba]

I thought it already looked for one, but no, it doesn't.