On 12 August 2016 at 13:38, eryk sun <eryksun@gmail.com> wrote:
... At this point what codepage does Python see? What codepage does process X see? (Note that they are both sharing the same console).
The input and output codepages are global data in conhost.exe. They aren't tracked for each attached process (unlike input history and aliases). That's how chcp.com works in the first place. Otherwise its calls to SetConsoleCP and SetConsoleOutputCP would be pointless.
That's what I expected, but hadn't had time to confirm (your point about chcp didn't occur to me). Thanks.
But IMHO all talk of using codepage 65001 is a waste of time. I think the trailing garbage output with this codepage in Windows 7 is unacceptable. And getting EOF for non-ASCII input is a show stopper. The problem occurs in conhost. All you get is the EOF result from ReadFile/ReadConsoleA, so it can't be worked around. This kills the REPL and raises EOFError for input(). ISTM the only people who think codepage 65001 actually works are those using Windows 8+ who occasionally need to print non-OEM text and never enter (or paste) anything but ASCII text.
Agreed, mucking with global state that subprocesses need was sufficient for me, but the other issues you mention seem conclusive. I understand Steve's point about being an improvement over 100% wrong, but we've lived with the current state of affairs long enough that I think we should take whatever time is needed to do it right, rather than briefly postponing the inevitable with a partial solution. Paul PS I've spent the last week on a different project trying to "save time" with partial solutions to precisely this issue, so apologies if I'm in a particularly unforgiving mood about it right now :-(