[Python-ideas] Infix functions

[Andrew Barnert]

On Feb 21, 2014, at 21:18, Haoyi Li <haoyi.sg at gmail.com> wrote:

> I like infix functions, but am no fan of the backtick syntax. Of all the things that backticks mean to people: quotes, finger-quotes, code-snippets, interpolate, whatever, "make me infix" is not one of them. Hard to type on a keyboard is almost a non-reason in comparison. I know Haskell does it, but... not that many people have used Haskell.
> 
> Another idea would be to go the Scala path and turn methods into infix operators, by letting you call point_a.add(point_b) as point_a add point_b or point_a @add point_b or some other special sigil. This is semantically different from using infix functions because your infix operators now do not clutter up your namespace, since they would be properties of the LHS object. Not sure if it's "Pythonic", whatever that means, but it's a neat idea that has found a lot of success in the Scala world and I think is superior to the various other mechanisms for infix-functions/operator-overloading that I see in Python/Ruby/C#/F#/etc.

As I said in the initial message, this is exactly what the Numeric guys suggested in the PEP back in the 2.1 days: "a @foo b" resolves to something like "a.__foo__(b)". They also wanted it to fall back to b.__rfoo__(a)".

By "something like" I do not mean "exactly". The original proposal relied on the fact that quoted method names, with non-identifier symbols in them, would replace double underscore names, so you'd have "@foo" and "r at foo" (and today's __add__ would be "+"). 

Anyway, I think functions make more sense than methods here, but I already explained why and don't want to repeat it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140222/95cb973e/attachment.html>