[Python-ideas] Infix functions

[Nathan Schneider]

On Sat, Feb 22, 2014 at 5:59 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> From: Hannu Krosing <hannu at krosing.net>
>
> Sent: Saturday, February 22, 2014 11:34 AM
>
>
> > On 02/22/2014 03:45 AM, Andrew Barnert wrote:
> >>  Sure, having an infinite number of easily-distinguishable operators
> that
>
> >> happen to have the precedence that fits your use case would be create.
> But we
> >> have a very limited set of operators. If you want element-wise
> multiplication,
> >> div, trued, and mod, there aren't any operators left with the right
> >> precedence for cross-multiplication, dot-product, and back-division.
> And even if
> >> that weren't an issue, using % to mean mod sometimes and cross-product
> other
> >> times is bound to be confusing to readers.
>
>
> > Why not use multiple "operator characters" for user-defined infix
> > operators, like postgreSQL does ?
> >
> > a *% b ++ c *% (d *. e)
>
> First, I'm not sure why everyone is focusing on the mathematical examples.


I have not seen a compelling use case for infix expressions other than
mathematical operators which currently require a method, thereby forcing an
order that does not match what we are used to writing. As has been argued,
conciseness is a virtue for the readability of complex mathematical
expressions.

Allowing Unicode symbols for operators would be nice in an ideal world, but
it seems like in practice it would create a lot of pain for very little
gain.

So I think the best compromise would be to allow current binary operators
to be augmented with a special character, such as ~ or : or `, such that
(a) new ambiguities would not be introduced into the grammar, and (b) the
precedence and dunder method name would be determined by the current
operator. Whether the operator has been "modified" with the special
character could be passed as an argument to the dunder method.


> I don't think PEP 225 covers why they rejected the idea in favor of just
> doubling the number of operators by adding a special ~ prefix, but there
> are two major problems.
>
>
> First, none of those sequences has any inherent meaning. I can guess what
> @cross means. If you just double the set of operators by allowing a ~
> prefix, I can guess that ~* is a variant on multiplication (I do have to
> know whether you're using ~* for element-wise and * for object-wise,
> Matlab-style, or vice-versa, R-style, but that's just one piece of
> information per project).


Using the special modifier character would tell the user that they have to
refer to the library documentation to interpret it. In fact, I think
builtins should be prohibited from supporting any of the modified
operators, so as to avoid establishing a default interpretation for any of
them. But presumably, most of the important use cases (e.g., cross product)
would have a conceptually related current operator (*), and would be
frequent enough that it would be worth the reader's time to look it up. For
rarer cases, there is little harm in just providing a method.


> If you have a whole suite of free-form operators made up of symbol
> strings, I have absolutely no idea what *% means.
>

Agreed, which is why I would be in favor of restricting ourselves to a
single modifier character that is not already an operator.

Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140223/3eea93a2/attachment-0001.html>