<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 5, 2017 at 1:18 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><br></div>I am very worried about this long and rambling PEP,</div></div></div></div></blockquote><div><br></div><div>FWIW, I read the PEP on the bus this morning on a phone, and while lng, I didn't find it too rambling. And this topic has been very often discussed in very long and rambling mailing list threads, etc. So I think a long (If not rambling) PEP is in order.</div><div><br></div><div>This is a very important topic for Python -- the py2-3 transition got a LOT of flack, to the point of people claiming that it was easier to learn a whole new language than convert to py3 -- and THIS particular issue was a big part of it:</div><div><br></div><div>The truth is that any system that does not use a clearly defined encoding for filenames (and everything else) is broken, plain and simple. But the other truth is (as talked about in the PEP) they some *nix systems are that broken because C code that simply passed around char* still works fine. And no matter how you slice it telling people that they need to fix their broken system in order for your software to run is not a popular option.</div><div><br></div><div>When Python added <font color="#500050">surrogateescape to its Unicode implementation, the tools were there to work with broken (OK, I'll be charitable: misconfigured) systems. Now we just need some easier defaults.</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">OK, now I'm getting long and rambling....</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">TL;DR -- The proposal in the PEP is an important step forward, and the issue is fraught with enough history and controversy that a long PEP is probably a good idea.</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">So the addition of a better summary of the specification up at the top, and editing of the rest, and we could have a good PEP.</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">Too late for this release, but what can you do?</font></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"><div dir="ltr"><div><div><div> The "Unicode just works" summary is more a wish than a proper summary of the PEP.<br></div></div></div></div></blockquote><div><br></div><div>well, yeah.</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"><div dir="ltr"><div><div></div>FWIW the relationship with PEP 538 is also pretty unclear. (Or maybe that's another case of the forest and the trees.) And that PEP (while already accepted) also comes across as rambling and vague, and I have no idea what it actually does. And it seems to mention PEP 540 quite a few times.<br></div></div></blockquote><div><br></div><div>I just took another look at 538 -- and yes, the relationship between the two is really unclear. In particular, with 538, why do we need 540? I honestly don't know.</div><div><br></div><div>-Chris</div><div><br></div></div>-- <br><div class="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></div>