<div dir="ltr"><br><br>On Thursday, July 21, 2016 at 11:45:11 AM UTC+5:30, Danilo J. S. Bellini wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"><div><br><div class="gmail_quote">2016-07-21 1:53 GMT-03:00 Pavol Lisy <span dir="ltr"><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="X-D7u7Q_CAAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">pavol...@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>On 7/20/16, Danilo J. S. Bellini <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="X-D7u7Q_CAAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">danilo....@gmail.com</a>> wrote:<br>
<br>
> 4. Unicode have more than one codepoint for some symbols that look alike,<br>
> for example "Σ𝚺𝛴𝜮𝝨𝞢" are all valid uppercase sigmas. There's also "∑",<br>
> but this one is invalid in Python 3. The italic/bold/serif distinction<br>
> seems enough for a distinction, and when editing a code with an Unicode<br>
> char like that, most people would probably copy and paste the symbol<br>
> instead of typing it, leading to a consistent use of the same symbol.<br>
<br>
</span>I am not sure what do you like to say, so for sure some info:<br>
<br>
PEP-3131 (<a href="https://www.python.org/dev/peps/pep-3131/" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.python.org%2Fdev%2Fpeps%2Fpep-3131%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEGPRT1udzVHWKG_2ZTOroW8Jqnpw';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.python.org%2Fdev%2Fpeps%2Fpep-3131%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEGPRT1udzVHWKG_2ZTOroW8Jqnpw';return true;">https://www.python.org/dev/<wbr>peps/pep-3131/</a>): "All identifiers<br>
are converted into the normal form NFKC while parsing; comparison of<br>
identifiers is based on NFKC."<br>
<br>
>From this point of view all sigmas are same:<br>
<br>
  set(unicodedata.normalize('<wbr>NFKC', i) for i in "Σ𝚺𝛴𝜮𝝨𝞢")  == {'Σ'}<br>
</blockquote></div><div><br></div><div>In this item I just said that most programmers would probably keep the same character in a source code file due to copying and pasting, and that even when it doesn't happen (the copy-and-paste action), visual differences like italic/bold/serif are enough for one to notice (when using another input method).</div><div><br></div><div>At first, I was thinking on a code with one of those symbols as a variable name (any of them), but PEP3131 challenges that. Actually, any conversion to a normal form means that one should never use unicode identifiers outside the chosen normal form. It would be better to raise an error instead of converting. </div></div></div></blockquote><div><br>Yes Agree<br>I said “Nice!” for<br><br>>>> Σ = 1<br>>>> 𝚺 = Σ + 1<br>>>> 𝛴<br>2<br><br>in comparison to:<br><br>>>> А = 1<br>>>> A = A + 1<br><br>because the A's look more indistinguishable than the sigmas and are internally more distinct<br> If the choice is to simply disallow the confusables that’s probably the best choice<br><br>IOW<br>1. Disallow co-existence of confusables (in identifiers)<br>2. Identify confusables to a normal form — like case-insensitive comparison and like NKFC<br>3. Leave the confusables to confuse<br> <br>My choice<br>1 better than 2 better than 3<br></div></div>