On 22May2017 1253, Paul Moore wrote:
It seems to me there are 2 schools of thought:
1. There are likely to be fewer front ends than back ends, and so the
front end(s) (basically, pip) should deal with the problem. Also,
backends are more likely to be written by developers who are looking
at very specific scenarios, and asking them to handle all the
complexities of robust multilingual coding is raising the bar on
writing a backend too high.
2. The backend is where the problem lies, and so the backend should
address the issue. Furthermore, a well-established principle in
dealing with encodings is to convert to strings right at the boundary
of the application, and in this case the backend is the only code that
has access to that boundary.
(I tend towards (2), but I honestly can't say to what extent that's
because it makes it "someone else's problem" for me ;-))
I also tend towards 2, and I assume I am one of the more likely people
to write the part that invokes Microsoft's cl.exe/link.exe :)
Is the front end going to be directly invoking those tools? I would
assume not, otherwise it won't be cross platform.
Since the shim belongs to the front end, I've essentially been ignoring
it. The shim can invoke another part of the build tool, but that is not
going to be cl.exe/link.exe either.
At some point there will be a script that runs the tools directly. I
have been referring to that as the backend, and it is the part that
should handle capturing and transcoding the output. Everything from
there can be utf8:replace to prevent crashing, but we can't say "the
frontend can handle all encodings", and shouldn't say "the frontend will
only use bad encodings".
IMHO, #2 is definitely the right way to go. Yes, the platform specific
code now has to worry about the encoding, but... the encoding is
platform specific? So... that seems exactly right? :) Maybe I'm still
missing something here, but I'm totally happy to leave it to Thomas to
decide (which I think he has, but I haven't gotten to looking at that PR
yet).
Cheers,
Steve
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
