nOn Tue, Jan 26, 2021 at 5:53 PM M.-A. Lemburg
Overall, I think the approach with two different binaries is not going work well. Users will get confused and many problems will arise due to users installing the wrong version for the apps they use.
We already let them choose between 64-bit and 32-bit and embedded vs. installer. Some may understand the consequences of installing a 32-bit version on a 64-bit OS, but I suppose most don't know what "embedded" is for (including myself :-)).
If you add UTF-8 vs. Locale dimensions on top, you'd create even more confusion.
OK. Confusing users only for getting stats is a bad idea...
I think it would be better to have the Windows installers get an option to set the PYTHONUTF8 env var for the user or system-wide. This would be off initially and default to on a few years later.
I like the idea, and it is almost the same to what I proposed in PEP
597 (2nd) in last year.
https://discuss.python.org/t/pep-597-enable-utf-8-mode-by-default-on-windows...
The difference with the PEP 597 (2nd) is now I propose to not change
the subprocess.PIPE encoding in UTF-8 mode.
I need to reconsider about stdin/stdout encoding when they are redirected.
Maybe, we can use GetConsoleCP() for stdin encoding, and
GetConsoleOutputCP() for output encoding. I will write another
proposal for it.
--
Inada Naoki