<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 November 2017 at 16:34, 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"><span class="gmail-">Nick Coghlan writes:<br>
<br>
 > We're not going to start second-guessing the Unicode Consortium on this<br>
 > point - human languages are complicated, and we don't have any special<br>
 > insight on this point that they don't.<br>
<br>
</span>Agreed.  Python, however, is NOT a (natural) human language, and the<br>
Unicode Consortium definition of conformance does NOT prohibit<br>
subsetting appropriate to the purpose.  We DO know more than the<br>
Unicode Consortium about Python.  For example, I suspect that your<br>
catholic appetite for XID in identifiers does not apply to syntactic<br>
keywords or names of builtins.<br></blockquote><div><br></div><div>We already have a stricter ASCII-only naming policy for the standard library: <a href="https://www.python.org/dev/peps/pep-3131/#policy-specification">https://www.python.org/dev/peps/pep-3131/#policy-specification</a></div><div><br></div><div>That's different from placing additional constraints on end-user code, though, as that's where the line between "programming language" and "natural language" gets blurry (variable, function, attribute, and method names are often nouns and verbs in the author's language, and this is also the case for data-derived APIs like pandas column names)<br></div><div><br></div>Cheers,</div><div class="gmail_quote">Nick.<br></div><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>