[Python-ideas] Partial operator (and 'third-party methods' and 'piping')

[Koos Zevenhoven]

Hi everyone!

(Sorry about double posting, but I wanted to start a new thread, which I 
tried but apparently failed to do last time. Although inspired by and 
related to the function composition discussion, this is now something 
different and should not be cluttering the composition thread.)

Reading the recent emails in the function composition thread started by 
Ivan, I realized that my sketch for a composition operator (from 
yesterday, quoted below) would be much better if it did not actually do 
function composition . Instead, -> would be quite powerful as 'just' a 
partial operator -- perhaps even more powerful, as I demonstrate below. 
However, this is not an argument against @ composition, which might in 
fact play together with this quite nicely.

This allows some nice things with multi-argument functions too.

I realize that it may be unlikely that a new operator would be added, 
but here it is anyway, as food for thought.  (With an existing operator, 
I suspect it would be even less likely, because of precedence rules : )

So, -> would be an operator with a precedence similar to .attribute 
access (but lower than .attribute):

  # The simple definition of what it does:
  arg->func   # equivalent to functools.partial(func, arg)

This would allow for instance:
  arg -> spam() -> cheese(kind = 'gouda') -> eggs()

which would be equivalent to eggs(cheese(spam(arg), kind = 'gouda'))

Or even together together with the proposed @ composition:
  rms = root @ mean @ square->map     # for an iterable non-numpy argument

And here's something I find quite interesting. Together with 
@singledispatch from 3.4 (or possibly an enhanced version using type 
annotations in the future?), one could add 'third-party methods' to 
classes in other libraries without monkey patching. A dummy example:

from numpy import array
my_list = [1,2,3]
my_array = array(my_list)
my_mean = my_array.mean()  # This currently works in numpy

from rmslib import rms
my_rms = my_array->rms()  # efficient rms for numpy arrays
my_other_rms = my_list->rms()  # rms that works on any iterable

One would be able to distinguish between calls to methods and 
'third-party methods' based on whether . or -> is used for accessing 
them, which I think is a good thing. Also, third-party methods would be 
less likely to mutate the object, just like func(obj) is less likely to 
mutate obj than obj.method().

See more examples below. I converted my examples from last night to this 
IMO better version, because at least some of them would still be relevant.

On 10.5.2015 2:07, Koos Zevenhoven wrote:
> On 10.5.2015 1:03, Gregory Salvan wrote:
>> Nobody convinced by arrow operator ?
>>
>> like: arg -> spam -> eggs -> cheese
>> or cheese <- eggs <- spam <- arg
>>
>>
>
> I like | a lot because of the pipe analogy. However, having a new 
> operator for this could solve some issues about operator precedence.
>
> Today, I sketched one possible version that would use a new .. 
> operator. I'll explain what it would do (but with your -> instead of 
> my ..)
>
> Here, the operator (.. or ->) would have a higher precedence than 
> function calls () but a lower precedence than attribute access 
> (obj.attr).
>
> First, with single-argument functions spam, eggs and cheese, and a 
> non-function arg:
>
> arg->eggs->spam->cheese()   # equivalent to cheese(spam(eggs(arg)))

With -> as a partial operator, this would instead be:

arg->eggs()->spam()->cheese()     # equivalent to cheese(spam(eggs(arg)))

> eggs->spam->cheese # equivalent to lambda arg: cheese(spam(eggs(arg)))
>

With -> as a partial operator this could be:

lambda arg: arg->eggs()->spam()->cheese()


> Then, if spam and eggs both took two arguments; eggs(arg1, arg2), 
> spam(arg1, arg2)
>
> arg->eggs   # equivalent to partial(eggs, arg)
> eggs->spam(a, b, c)   # equivalent to spam(eggs(a, b), c)

With -> as a partial operator, the first one would work, and the second 
would become:

eggs(a,b)->spam(c)     # equivalent to spam(eggs(a, b), c)

> arg->eggs->spam(b,c) # equivalent to spam(eggs(arg, b), c)
>

This would become:

arg->eggs(b)->spam(c)     # equivalent to spam(eggs(arg, b), c)

Note that this would be quite flexible in partial 'piping' of 
multi-argument functions.

> So you could think of -> as an extended partial operator. And this 
> would naturally generalize to functions with even more arguments. The 
> arguments would always be fed in the same order as in the equivalent 
> function call, which makes for a nice rule of thumb. However, I 
> suppose one would usually avoid combinations that are difficult to 
> understand.
>
> Some examples that this would enable:
>
>  # Example 1
>  from numpy import square, mean, sqrt
>  rms = square->mean->sqrt  # I think this order is fine because it is 
> not @
>

This would become:

def rms(arr):
     return arr->square()->mean()->sqrt()

>  # Example 2 (both are equivalent)
>  spam(args)->eggs->cheese() # the shell-syntax analogy that Steven 
> mentioned.
>

This would be:

spam(args)->eggs()->cheese()

Of course the shell piping analogy would be quite far, because it looks 
so different.

>  # Example 3
>  # Last but not least, we would finally have this
>  some_sequence->len()
>  some_object->isinstance(MyType)
>

And:

  func->map(seq)
  func->reduce(seq)

-- Koos