<div dir="ltr"><div><div><div><div><div><div><div><div>It seems to me that having a C locale can mean two things:<br><br></div>1) It really is meant to be ASCII<br><br></div>2) It's mis-configured (or un-configured), meaning the system encoding is unknown.<br><br></div>if (2) then utf-8 is a fine default.<br><br></div>if (2), then there are two options:<br><br></div>1) Everything on the sytsem really is ASCII -- in which case, utf-8 would "just work" -- no problem.<br><br></div>2) There are non-ascii file names, etc. on this supposedly ASCII system. In which case, do folks expect their Python programs to find these issues and raise errors? They may well expect that their Python program will not let them try to save a non ASCII filename, for instance. But I suspect that they wouldn't want it to raise an obscure encoding error -- but rather would want the app to do somethign friendly.<br><br></div>So I see no downside to using utf-8 when the C locale is defined.<br><br></div>-CHB<br><br><div><div><div><div><div><br><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 11, 2017 at 4:23 PM, INADA Naoki <span dir="ltr"><<a href="mailto:songofacandy@gmail.com" target="_blank">songofacandy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> My PEP 540 is different than Nick's PEP 538, even for the POSIX<br>
> locale. I propose to always use the surrogateescape error handler,<br>
> whereas Nick wants to keep the strict error handler for inputs and<br>
> outputs.<br>
> <a href="https://www.python.org/dev/peps/pep-0540/#encoding-and-error-handler" rel="noreferrer" target="_blank">https://www.python.org/dev/<wbr>peps/pep-0540/#encoding-and-<wbr>error-handler</a><br>
><br>
> The surrogateescape error handler is useful to write programs which<br>
> work as pipes, as cat, grep, sed, ... UNIX program:<br>
> <a href="https://www.python.org/dev/peps/pep-0540/#producer-consumer-model-using-pipes" rel="noreferrer" target="_blank">https://www.python.org/dev/<wbr>peps/pep-0540/#producer-<wbr>consumer-model-using-pipes</a><br>
><br>
> You can get the behaviour of Nick's PEP 538 using my UTF-8 Strict<br>
> mode. Compare "UTF-8 mode" and "UTF-8 Strict mode" lines in the tables<br>
> of my use case. The UTF-8 mode always works, but can produce mojibake,<br>
> whereas UTF-8 Strict doesn't produce mojibake but can fail depending<br>
> on data and the locale.<br>
><br>
> IMHO most users prefers usability ("just work") over correctness<br>
> (prevent mojibake).<br>
><br>
<br>
</span>I'm ±0 to surrogateescape by default.  I feel +1 for stdout and -1 for stdin.<br>
<br>
In output case, surrogateescape is weaker than strict, but it only allows<br>
surrgateescaped binary.  If program carefully use surrogateescaped decode,<br>
surrogateescape on stdout is safe enough.<br>
<br>
On the other hand, surrogateescape is very weak for input.  It accepts<br>
arbitrary bytes.<br>
It should be used carefully.<br>
<br>
But I agree different encoding handler between stdin/stdout is not beautiful.<br>
That's why I'm ±0.<br>
<br>
<br>
FYI, when <a href="http://bugs.python.org/issue15216" rel="noreferrer" target="_blank">http://bugs.python.org/<wbr>issue15216</a> is merged, we can change<br>
error handler easily: ``sys.stdout.set_encoding(<wbr>errors='surrogateescape')``<br>
<br>
So it's controllable from Python.  Some program which handles filenames may<br>
prefer surrogateescape, and some program like CGI may prefer strict<br>
UTF-8 because<br>
JSON and HTML5 shouldn't contain arbitrary bytes.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a></div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div>