On 23 May 2017 at 05:11, Nick Coghlan 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
On Tue, May 23, 2017, at 09:08 AM, Paul Moore wrote:
> I strongly
> prefer using the locale encoding as the assumed encoding for the
> output stream rather than UTF-8.
I may have missed it, but has anyone proposed what it should do if it
wants to send characters which can't be encoded in the local
On 23 May 2017 at 09:56, Thomas Kluyver wrote:
> I may have missed it, but has anyone proposed what it should do if it
> wants to send characters which can't be encoded in the locale encoding?
No, it's not been mentioned - the focus has been on running build
tools like a compiler. Best answer I c
On Tue, May 23, 2017, at 11:04 AM, Paul Moore wrote:
> However, if we do this then we have a situation where existing build
> tools (compilers, etc) that we have to support still use platform
> dependent encodings. That's a reality that we can't wish away. And the
> majority of real-life issues rep
On 23 May 2017 at 12:36, Thomas Kluyver wrote:
> As you described earlier, though, even using a locale dependent encoding
> doesn't really avoid this problem, because of tools using OEM vs ANSI
> codepages on Windows. And if PYTHONIOENCODING is set, Python processes
> will use that over the locale
On Tue, May 23, 2017, at 12:56 PM, Paul Moore wrote:
> So based on your proposal, won't you introduce similar bugs by using
> print() without sorting out encodings? Unless (see below) you assume
> that the frontend sorts it out for you.
If you strictly follow the locale encoding, you need to sort
On 23 May 2017 at 13:41, Thomas Kluyver wrote:
> Can I take a quick poll of what people following this topic think?
>
> Q1: Default encoding for captured build stdout/stderr
> a. UTF-8 (consistent, can represent any character)
> b. Locale default (convenient if backend runs subprocesses which prod
On 23 May 2017 at 22:41, Thomas Kluyver wrote:
> On Tue, May 23, 2017, at 12:56 PM, Paul Moore wrote:
> Can I take a quick poll of what people following this topic think?
>
> Q1: Default encoding for captured build stdout/stderr
> a. UTF-8 (consistent, can represent any character)
> b. Locale defa
On 23 May 2017 at 16:20, Nick Coghlan wrote:
> Taking that approach of just defining a helper API and expecting build
> backends to either use it or emulate it gives us some quite attractive
> properties:
Making the output data part of a structured API (and by implication,
saying that backends sh
On 24 May 2017 at 01:39, Paul Moore wrote:
> On 23 May 2017 at 16:20, Nick Coghlan wrote:
>> Taking that approach of just defining a helper API and expecting build
>> backends to either use it or emulate it gives us some quite attractive
>> properties:
>
> Making the output data part of a structu
On 23 May 2017 at 17:16, Nick Coghlan wrote:
> Yep, and that's also why I want to avoid trying to use it to improve
> the encoding handling situation - pip and other tools have to deal
> with the current mess regardless, and there's already likely to be
> some significant churn in this space as a
On Tue, May 23, 2017, at 04:20 PM, Nick Coghlan wrote:
> Up to this point, I've been in favour of both 1b and 2b, since they're
Noted.
> However, I also realised that there's a potential third way to handle
> this problem: design a Python level API that allows front ends to use
> more structured
A couple comments:
1) Would it make sense to provide a way for build tools to specify
what encoding they use (e.g. if not using the default), instead of
changing their encoding to conform to a standard? It seems like that
could be easier, although I know this doesn't address problems like
non-conf
13 matches
Mail list logo
