<div dir="ltr"><div><div><div><div><div><div><div><div>In my opinion, this syntax make problems when your arguments are functions/callables.<br>And if you code in a functionnal paradigm it is quite common to inject functions in arguments otherwise how would you do polymorphism ?<br><br></div>The only way I see to distinguish cases is to have tuples, but syntax is quite strange.<br><br>instead of : arg->eggs(b)->spam(c)<br></div>my_partial = (arg, b)->eggs->(c, )->spam<br><br></div>Then how would you call my_partial ?<br></div>For example, if you have:<br></div>def eggs(a, b, c)...<br></div>def spam(d, e)...<br><br></div>my_partial(c, e) or my_partial(c)(e) ?<br></div><div><br><div><div><div><div><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-10 22:06 GMT+02:00 Koos Zevenhoven <span dir="ltr"><<a href="mailto:koos.zevenhoven@aalto.fi" target="_blank">koos.zevenhoven@aalto.fi</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Reading the recent emails in the function composition thread started by Ivan, I realized that my below sketch for a composition operator would be 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.<br>
<br>
This allows some nice things with multi-argument functions too.<br>
<br>
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 : )<br>
<br>
So, -> would be an operator with a precedence similar to .attribute access (but lower than .attribute):<br>
<br>
 # The simple definition of what it does:<br>
 arg->func   # equivalent to functools.partial(func, arg)<br>
<br>
This would allow for instance:<br>
 arg -> spam() -> cheese(kind = 'gouda') -> eggs()<br>
<br>
which would be equivalent to eggs(cheese(spam(arg), kind = 'gouda'))<br>
<br>
Or even together together with the proposed @ composition:<br>
 rms = root @ mean @ square->map     # for an iterable non-numpy argument<br>
<br>
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:<br>
<br>
from numpy import array<br>
my_list = [1,2,3]<br>
my_array = array(my_list)<br>
my_mean = my_array.mean()  # This currently works in numpy<br>
<br>
from rmslib import rms<br>
my_rms = my_array->rms()  # efficient rms for numpy arrays<br>
my_other_rms = my_list->rms()  # rms that works on any iterable<br>
<br>
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().<br>
<br>
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.<br>
<br>
On 10.5.2015 2:07, Koos Zevenhoven wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10.5.2015 1:03, Gregory Salvan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nobody convinced by arrow operator ?<br>
<br>
like: arg -> spam -> eggs -> cheese<br>
or cheese <- eggs <- spam <- arg<br>
<br>
<br>
</blockquote>
<br>
I like | a lot because of the pipe analogy. However, having a new operator for this could solve some issues about operator precedence.<br>
<br>
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 ..)<br>
<br>
Here, the operator (.. or ->) would have a higher precedence than function calls () but a lower precedence than attribute access (obj.attr).<br>
<br>
First, with single-argument functions spam, eggs and cheese, and a non-function arg:<br>
<br>
arg->eggs->spam->cheese()   # equivalent to cheese(spam(eggs(arg)))<br>
</blockquote>
<br>
With -> as a partial operator, this would instead be:<br>
<br>
arg->eggs()->spam()->cheese()     # equivalent to cheese(spam(eggs(arg)))<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
eggs->spam->cheese  # equivalent to lambda arg: cheese(spam(eggs(arg)))<br>
<br>
</blockquote>
<br>
With -> as a partial operator this could be:<br>
<br>
lambda arg: arg->eggs()->spam()->cheese()<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then, if spam and eggs both took two arguments; eggs(arg1, arg2), spam(arg1, arg2)<br>
<br>
arg->eggs   # equivalent to partial(eggs, arg)<br>
eggs->spam(a, b, c)   # equivalent to spam(eggs(a, b), c)<br>
</blockquote>
<br>
With -> as a partial operator, the first one would work, and the second would become:<br>
<br>
eggs(a,b)->spam(c)     # equivalent to spam(eggs(a, b), c)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
arg->eggs->spam(b,c)    # equivalent to spam(eggs(arg, b), c)<br>
<br>
</blockquote>
<br>
This would become:<br>
<br>
arg->eggs(b)->spam(c)     # equivalent to spam(eggs(arg, b), c)<br>
<br>
Note that this would be quite flexible in partial 'piping' of multi-argument functions.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
Some examples that this would enable:<br>
<br>
 # Example 1<br>
 from numpy import square, mean, sqrt<br>
 rms = square->mean->sqrt  # I think this order is fine because it is not @<br>
<br>
</blockquote>
<br>
This would become:<br>
<br>
def rms(arr):<br>
    return arr->square()->mean()->sqrt()<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 # Example 2 (both are equivalent)<br>
 spam(args)->eggs->cheese() # the shell-syntax analogy that Steven mentioned.<br>
<br>
</blockquote>
<br>
This would be:<br>
<br>
spam(args)->eggs()->cheese()<br>
<br>
Of course the shell piping analogy would be quite far, because it looks so different.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 # Example 3<br>
 # Last but not least, we would finally have this :)<br>
 some_sequence->len()<br>
 some_object->isinstance(MyType)<br>
<br>
</blockquote>
<br>
And:<br>
<br>
 func->map(seq)<br>
 func->reduce(seq)<br>
<br>
-- Koos<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div><br></div>