<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-11-21 12:55 GMT+01:00 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>:<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.  </blockquote><div><br></div><div>That would be quite a backward-incompatible change since <br></div><div>such identifiers have been legal since Python 3.0.<br></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">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 "_".  </blockquote><div><br></div><div>See:<br></div><div><a href="https://www.python.org/dev/peps/pep-313">https://www.python.org/dev/peps/pep-313</a><br></div><div> </div><div>The identifier syntax is <tt class="gmail-docutils gmail-literal"><XID_Start> <XID_Continue>*</tt>.</div><div><tt class="gmail-docutils gmail-literal"><br></tt></div><div><tt class="gmail-docutils gmail-literal">ID_Start</tt> is defined as all characters having one of the general
categories uppercase letters (Lu), lowercase letters (Ll), titlecase
letters (Lt), modifier letters (Lm), other letters (Lo), letter
numbers (Nl), the underscore, and characters carrying the
Other_ID_Start property. <tt class="gmail-docutils gmail-literal">XID_Start</tt> then closes this set under
normalization, by removing all characters whose NFKC normalization
is not of the form ID_Start ID_Continue* anymore.</div><div>
<p><tt class="gmail-docutils gmail-literal">ID_Continue</tt> is defined as all characters in <tt class="gmail-docutils gmail-literal">ID_Start</tt>, plus
nonspacing marks (Mn), spacing combining marks (Mc), decimal number
(Nd), connector punctuations (Pc), and characters carryig the
Other_ID_Continue property. Again, <tt class="gmail-docutils gmail-literal">XID_Continue</tt> closes this set
under NFKC-normalization; it also adds U+00B7 to support Catalan.</p></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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>If we take this thinking to its logical extreme we should ban ASCII 1 and l</div><div>since they can be confused. Also 0 and O.</div><div><br></div><div>Realistically, this is extremely unlikely to be an issue in practice.</div><div>If you have people making such malignant code changes</div><div>with checkin permission, you have bigger problems...</div><div><br></div><div>Anyway, you can have your linter enforce ASCII or whatever</div><div>character subset you deem safe.<br></div><div><br></div><div>Stephan<br></div></div></div></div>