On 23 May 2017 at 05:11, Nick Coghlan <ncogh...@gmail.com> wrote: > What we can then also do is to recommend that *front-ends* do the > following when invoking their build backend CLI shims: > > 1. Implement the C locale -> UTF-8 based locale coercion defined in > PEP 538 when launching the subprocess > 2. Implement a similar coercion for Windows, where cp1252 being active > in the parent process prompts a call to "'chcp cp65001'" inside the > subprocess before the build backend itself actually starts running
I'm a fairly strong -1 on doing "chcp 65001" on Windows. It puts the backend into a position of running under a relatively non-standard environment, and therefore runs the risk of provoking issues. If a build tool has issues as a result of the changed codepage, who's responsible for dealing with the bug? The backend, that manages the tool, or the frontend, that set the codepage? One of the big issues we have is that very few people have expertise in this area (encodings on Windows) and so keeping the environment as "standard" as we can ensures that we can make best use of the limited expertise we have. I agree with Thomas that we're probably reaching a point of diminishing returns. But on one point I remain in dispute - I strongly prefer using the locale encoding as the assumed encoding for the output stream rather than UTF-8. Also (although this is a quality of implementation issue) I think that the frontend (i.e.the shim) should *not* make any changes to the global environment that the backend runs in. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig