<div dir="ltr">Hi Petr,<br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-11 12:22 GMT+01:00 Petr Viktorin <span dir="ltr"><<a href="mailto:encukou@gmail.com" target="_blank">encukou@gmail.com</a>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For example, this may mean that a built-in Python string sort will give you<br>
a different ordering than invoking the external "sort" command.<br>
I have been bitten by this kind of issues, leading to spurious "diffs" if<br>
you try to use sorting to put strings into a canonical order.<br>
</blockquote>
<br></span>
AFAIK, this would not be a problem under PEP 538, which effectively treats the "C" locale as "C.UTF-8". Strings of Unicode codepoints and the corresponding UTF-8-encoded bytes sort the same way.<br></blockquote><div><br></div><div>...and this is also something new I learned.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Is that wrong, or do you have a better example of trouble with using "C.UTF-8" instead of "C"?</blockquote><div><br></div><div><br></div><div>After long deliberation, it seems I cannot find any source of trouble. +1<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So my feeling is that people are ultimately not being helped by<br>
Python trying to be "nice", since they will be bitten by locale issues<br>
anyway. IMHO ultimately better to educate them to configure the locale.<br>
(I realise that people may reasonably disagree with this assessment ;-) )<br>
<br>
I would then recommend to set to en_US.UTF-8, which is slower and<br>
less elegant but at least more widely supported.<br>
</blockquote>
<br></span>
What about the spurious diffs you'd get when switching from "C" to "en_US.UTF-8"?<br></blockquote><div><br></div><div>That taught me to explicitly invoke "sort" using</div><div>LANG=en_US.UTF-8 sort</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br></span>
I believe the main problem is that the "C" locale really means two very different things:<br>
<br>
a) Text is encoded as 7-bit ASCII; higher codepoints are an error<br>
b) No encoding was specified<br>
<br>
In both cases, treating "C" as "C.UTF-8" is not bad:<br>
a) For 7-bit "text", there's no real difference between these locales<br>
b) UTF-8 is a much better default than ASCII<br><br></blockquote><div><br></div><div>A "C" locale also means that a program should not *output* non-ASCII characters,</div><div>unless when explicitly being fed in (like in the case of "cat" or "sort" or the "ls" equivalent from PEP-540).</div><div><br></div><div>So for example, a program might want to print fancy Unicode box characters to show</div><div>progress, and check sys.stderr.encoding to see if it can do so.</div><div>However, under a "C" locale it should not do so since for example the terminal</div><div>is unlikely to display the fancy box characters properly.</div><div><br></div><div>Note that the current PEP 540 proposal would be that sys.stderr is in UTF-8 /backslashreplace encoding</div><div>under the "C" locale.</div><div><br></div><div>I think this may be a minor concern ultimately, but it would be nice if we had some API to</div><div>at least reliable answer the question "can I safely output non-ASCII myself?"</div><div><br></div><div>Stephan </div></div></div></div>