On Sat, May 20, 2017, at 05:36 PM, Steve Dower wrote: > I'll probably read the PEP closely and see that this is entirely > incorrect, but if it's right: > > * encoding for text between the build UI and build tool should just be > specified once for all platforms (i.e. use UTF-8).
+1 > * encoding for text between build tool and the compiler depends on the > compiler > > In general, since most subprocesses (at least on Windows) do not have > customizable encodings, the tool that launches them needs to know what > the encoding is. Since we don't live in a Python 3.6 world quite yet, > that means the tool should read raw bytes from the compiler and encode > them to UTF-8. I half agree, but: - Build tools may not 100% know what encoding output will be produced, especially if the developer can supply a custom command for the build tool to run. - It's possible for data on a pipe to be binary data with no meaning as text. - As a lazy developer, I don't want to read stdout/stderr from a subprocess only to spit it back to my own stdout/stderr. I'd much rather just launch the subprocess and let it use the same stdout/stderr as my build tool. So I think it's most practical to recommend that build tools produce UTF-8 (if not sys.stdout.isatty()), but let build tool developers decide how far they go to comply with that. Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig