[Python-ideas] Is there a good reason to use * for multiplication?

[MRAB]

On 2012-10-14 23:42, Joshua Landau wrote:
> On 14 October 2012 23:08, MRAB <python at mrabarnett.plus.com
> <mailto:python at mrabarnett.plus.com>> wrote:
>
>     On 2012-10-14 22:06, Joshua Landau wrote:
>
>         On 14 October 2012 20:57, Mike Meyer <mwm at mired.org
>         <mailto:mwm at mired.org>
>         <mailto:mwm at mired.org <mailto:mwm at mired.org>>> wrote:
>
>              On Sun, 14 Oct 2012 07:40:57 +0200
>              Yuval Greenfield <ubershmekel at gmail.com
>         <mailto:ubershmekel at gmail.com>
>              <mailto:ubershmekel at gmail.com
>         <mailto:ubershmekel at gmail.com>>__> wrote:
>
>               > On Sun, Oct 14, 2012 at 2:04 AM, MRAB
>         <python at mrabarnett.plus.com <mailto:python at mrabarnett.plus.com>
>              <mailto:python at mrabarnett.__plus.com
>         <mailto:python at 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!
>
>                   <mike
>
>
>         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.
>
>
> No, no. "\\" would have priority, still. "\\uXXXX" is invalid outside of
> a string, anyway, so we're allowed to say that.
>
OK, but what about raw string literals? Currently, "\\u0190" ==
r"\u0190", but "\\u0190" != r"Ɛ".