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