[Python-ideas] Infix functions

[Andrew Barnert]

From: Chris Rebert <pyideas at rebertia.com>

Sent: Friday, February 21, 2014 2:47 PM


> On Fri, Feb 21, 2014 at 2:05 PM, Andrew Barnert <abarnert at yahoo.com> 
> wrote:
>>  While we're discussing crazy ideas inspired by a combination of a 
> long-abandoned PEP and Haskell idioms (see the implicit lambda thread), 
> here's another: arbitrary infix operators:
>> 
>>      a `foo` b == foo(a, b)
> 
> Prior discussion:
> https://mail.python.org/pipermail/python-ideas/2007-January/000050.html
> 
> Which resulted in a new item in PEP 3099 ("Things that will Not Change
> in Python 3000"; http://legacy.python.org/dev/peps/pep-3099/ ):
>     * No more backticks.
>     Backticks (`) will no longer be used as shorthand for repr -- but
> that doesn't mean they are available for other uses. Even ignoring the
> backwards compatibility confusion, the character itself causes too
> many problems (in some fonts, on some keyboards, when typesetting a
> book, etc).
> 
> 
> I think people using suboptimal fonts and keyboard layouts should find
> better ones...


Thanks for pointing that out.

OK, some other syntax then, there's no reason it has to be identical to Haskell. We can even go back to the original PEP's version:

    a @foo b = foo(a, b)

… or, more likely, come up with something better. The important question here is whether there's something _worthy_ of new syntax; what that new syntax should be is just bikeshedding.

The other main negative consideration from that thread came from mapping custom operators to custom magic methods. I explained in the initial post why I think that's a bad idea, and not necessary. Just map it to a plain old function call, and use generic dispatch if you need to.

I think the mathematical example I gave shows how this can be more readable than normal function or method calls:

    a @cross b + c @cross (d @dot e)
    a.cross(b).add(c.cross(d.dot(e)))
    add(cross(a, b), cross(c, dot(d, e))


And the Haskell `catch` example shows how it _might_ be useful for other things, like higher-order function calls, but I haven't come up with a higher-order _Python_ function where it makes sense—and if there isn't one, the proposal is unnecessary.