<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 November 2017 at 21:55, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp" target="_blank">turnbull.stephen.fw@u.tsukuba.ac.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Personally, I think that Python probably should ban non-ASCII<br>
non-letter characters in identifiers and whitespace, and maybe add<br>
them later in response to requests from native speakers of the<br>
relevant languages.  I don't know how easy that would be to do,<br>
though, since I think the rule is already that identifiers must be<br>
composed only of letters, numbers, and ASCII "_".  Since Serhiy's<br>
examples are valid, we'd have to rule them out explicitly, rather than<br>
by reference to the Unicode database.  Yuck.<br></blockquote><div><br></div><div>We're not going to start second-guessing the Unicode Consortium on this point - human languages are complicated, and we don't have any special insight on this point that they don't. <a href="https://www.python.org/dev/peps/pep-3131/#specification-of-language-changes">https://www.python.org/dev/peps/pep-3131/#specification-of-language-changes</a> delegated this aspect of the language to them by way of the XID_Start and the XID_Continue categories, and we're not going to change that.</div><div><br><div><div>Any hybrid Python 2/3 application or library is necessarily restricted to ASCII-only identifiers, since that's all that Python 2 supports.<br></div><div><br></div></div></div><div>We've also explicitly retained the ASCII-only restriction for PyPI distribution names (see <a href="https://www.python.org/dev/peps/pep-0508/#names">https://www.python.org/dev/peps/pep-0508/#names</a>), but that doesn't restrict the names used for import packages, only the names used to publish and install those components. If we ever decide to lift that restriction, it will likely be by way of <a href="https://en.wikipedia.org/wiki/Punycode">https://en.wikipedia.org/wiki/Punycode</a>, similar to the way internationalized domain names work, as well as the way multi-phase extension module initialization locates init functions for extension modules with non-ASCII names.</div><div><br></div><div>Beyond that, I'll note that these questions were all raised in the original PEP: <a href="https://www.python.org/dev/peps/pep-3131/#open-issues">https://www.python.org/dev/peps/pep-3131/#open-issues</a></div><div><br></div><div>The reference interpreter really isn't the place to experiment with answering them - rather, they're more a question for opt-in code analysis, since that makes it possible for folks to choose settings that are right *for them* (e.g. by defining a set of "permitted scripts" [1], specifying the Unicode characters that should be allowed in identifiers beyond the core set of "Latin" code points allowed by ASCII)<br></div><br></div>Cheers,</div><div class="gmail_extra">Nick.</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="https://en.wikipedia.org/wiki/Script_(Unicode)">https://en.wikipedia.org/wiki/Script_(Unicode)</a><br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>