On 14 October 2012 23:08, MRAB <span dir="ltr"><<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.plus.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 2012-10-14 22:06, Joshua Landau wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 14 October 2012 20:57, Mike Meyer <<a href="mailto:mwm@mired.org" target="_blank">mwm@mired.org</a><br></div><div class="im">
<mailto:<a href="mailto:mwm@mired.org" target="_blank">mwm@mired.org</a>>> wrote:<br>
<br>
    On Sun, 14 Oct 2012 07:40:57 +0200<br>
    Yuval Greenfield <<a href="mailto:ubershmekel@gmail.com" target="_blank">ubershmekel@gmail.com</a><br></div><div class="im">
    <mailto:<a href="mailto:ubershmekel@gmail.com" target="_blank">ubershmekel@gmail.com</a>><u></u>> wrote:<br>
<br>
     > On Sun, Oct 14, 2012 at 2:04 AM, MRAB <<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.plus.com</a><br></div><div><div class="h5">
    <mailto:<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.<u></u>plus.com</a>>> wrote:<br>
     ><br>
     > > If it's more than one codepoint, we could prefix with the<br>
    length of the<br>
     > > codepoint's name:<br>
     > ><br>
     > > def __12CIRCLED_PLUS__(x, y):<br>
     > >     ...<br>
     > ><br>
     > ><br>
     > That's a bit impractical, and why reinvent the wheel? I'd much<br>
    rather:<br>
     ><br>
     > def \u2295(x, y):<br>
     >     ....<br>
     ><br>
     > So readable I want to read it twice. And that's not legal python<br>
    today so<br>
     > we don't break backwards compatibility!<br>
<br>
    Yes, but we're defining an operator for instances of the class, so it<br>
    needs the 'special' method marking:<br>
<br>
    def __\u2295__(self, other):<br>
<br>
    Now *that's* pretty!<br>
<br>
         <mike<br>
<br>
<br>
I much preferred your first choice:<br>
def __$⊕__(self, other):<br>
<br>
But to keep the "$" unused we can write:<br>
def __op_⊕__(self, other):<br>
(new methods will take precedence over the older __add__ and so forth)<br>
<br>
What we can do then is use the "\u" syntax to let people without unicode<br>
editors have accessibility:<br>
def __op_\u2295__(self, other):<br>
...later in the code...<br>
new = first \u2295 second<br>
<br>
Which adds consistency whereas before we could only use that in<br>
specific circumstances (inside strings), reducing cognitive burden.<br>
<br>
</div></div></blockquote>
I don't think we should change what happens inside a string literal.<br>
<br>
Consider what would happen if you wanted to write "\\u0190". It would<br>
convert that into "\Ɛ".<br>
<br>
IIRC, Java can suffer from that kind of problem because \uXXXX is<br>
treated as that codepoint wherever it occurs.</blockquote><div><br></div><div>No, no. "\\" would have priority, still. "\\uXXXX" is invalid outside of a string, anyway, so we're allowed to say that. </div>

</div><br>