On 14 October 2012 23:08, MRAB <firstname.lastname@example.org> wrote:
On 2012-10-14 22:06, Joshua Landau wrote:
I don't think we should change what happens inside a string literal.On 14 October 2012 20:57, Mike Meyer <email@example.com<mailto:firstname.lastname@example.org>> wrote:
On Sun, 14 Oct 2012 07:40:57 +0200
Yuval Greenfield <email@example.com<mailto:firstname.lastname@example.org>> wrote:
> On Sun, Oct 14, 2012 at 2:04 AM, MRAB <email@example.com<mailto:firstname.lastname@example.org>> 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
> def \u2295(x, y):
> So readable I want to read it twice. And that's not legal python
> 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.
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.