On 20May2017 0820, Nick Coghlan wrote:
Good point regarding the fact that the Windows 16-bit APIs only come
into play for interactive sessions (even in 3.6+), while for PEP 517
we're specifically interested in the 8-bit pipes used to communicate
with build subprocesses launched by an installation tool.
I need to catch up on the PEP (and thanks Brett for alerting me to the
thread), but this comment in particular cements the mental diagram I
have right now:
(build UI) <--> (build tool) <--> (compiler)
( Python ) <--> ( Python ) <--> (anything)
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).
* 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.
The encoding between the tool and UI is essentially irrelevant - the UI
is going to transform the data anyway for display, and the tool is going
to have to transform it from the compilation tools, so the best we can
do is pick the most likely encoding to avoid too many operations. UTF-8
is probably that.
That's my 0.02AUD based on a vague memory of the PEP and this thread. As
I get time today (at PyCon) to read up on it I may post amendments, but
in general I'm +100 on "just pick an encoding and make the
implementations transcode".
Cheers,
Steve
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
