On 20May2017 1011, Thomas Kluyver wrote:
On Sat, May 20, 2017, at 05:36 PM, Steve Dower wrote:
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.
In this case, the whole thing breaks down anyway. UI can't be expected
to reliably display text from an unknown encoding - at some point it has
to be forced into a known quantity, and IMHO the code closest to the
tool should do it.
- It's possible for data on a pipe to be binary data with no meaning as
text.
Sure, but it cannot be rendered unless you choose an encoding. All you
can do is dump it to a file (and let a file editor choose an encoding).
- 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.
One of the open issues against distutils is that it does this. We can
allow it, but a well-defined tool should capture the output and pass it
to the UI component rather than bypassing the UI component.
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.
Require that build tools either send UTF-8 to the UI component, or write
bytes to a file and call it a build output. I see no benefit in
requiring both the build tool and the UI tool to guess what the text
encoding is.
Cheers,
Steve
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
