<div dir="ltr"><div><div><div><div><div>Dear Erik,<br><br></div>Thank you for the link! I agree that this idea is too raw for stdlib (there are problems with many argument functions, keyword arguments, etc.)<br></div>Concerning the shell | vs. matrix @ I think it is a good idea to have both... but with different order.<br></div>I mean in shell logic f | g means g (f (x)), while for matrix multiplication f @ g means f(g(x)).<br></div>The former is probably more natural for people with more "programming" background, while the latter is more natural for people with a "scientific" background.<br></div>We could now do good for both, since we now have a new operator.<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 May 2015 at 16:10, Erik Bray <span dir="ltr"><<a href="mailto:erik.m.bray@gmail.com" target="_blank">erik.m.bray@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, May 6, 2015 at 9:20 AM, Ivan Levkivskyi <<a href="mailto:levkivskyi@gmail.com">levkivskyi@gmail.com</a>> wrote:<br>
> Dear all,<br>
><br>
> The matrix multiplication operator @ is going to be introduced in Python 3.5<br>
> and I am thinking about the following idea:<br>
><br>
> The semantics of matrix multiplication is the composition of the<br>
> corresponding linear transformations.<br>
> A linear transformation is a particular example of a more general concept -<br>
> functions.<br>
> The latter are frequently composed with ("wrap") each other. For example:<br>
><br>
> plot(real(sqrt(data)))<br>
><br>
> However, it is not very readable in case of many wrapping layers. Therefore,<br>
> it could be useful to employ<br>
> the matrix multiplication operator @ for indication of function composition.<br>
> This could be done by such (simplified) decorator:<br>
><br>
> class composable:<br>
><br>
>     def __init__(self, func):<br>
>         self.func = func<br>
><br>
>     def __call__(self, arg):<br>
>         return self.func(arg)<br>
><br>
>     def __matmul__(self, other):<br>
>         def composition(*args, **kwargs):<br>
>             return self.func(other(*args, **kwargs))<br>
>         return composable(composition)<br>
><br>
> I think using such decorator with functions that are going to be deeply<br>
> wrapped<br>
> could improve readability.<br>
> You could compare (note that only the outermost function should be<br>
> decorated):<br>
><br>
> plot(sorted(sqrt(real(data_array)))) vs. (plot @ sorted @ sqrt @ real)<br>
> (data_array)<br>
><br>
> I think the latter is more readable, also compare<br>
><br>
> def sunique(lst):<br>
>     return sorted(list(set(lst)))<br>
><br>
> vs.<br>
><br>
> sunique = sorted @ list @ set<br>
><br>
> Apart from readability, there are following pros of the proposed decorator:<br>
><br>
> 1. Similar semantics as for matrix multiplication.<br>
> 2. Same symbol for composition as for decorators.<br>
> 3. The symbol @ resembles mathematical notation for function composition: ∘<br>
><br>
> I think it could be a good idea to add such a decorator to the stdlib<br>
> functools module.<br>
<br>
</div></div>In the astropy.modeling package, which consists largely of collection<br>
of fancy wrappers around analytic functions,<br>
we used the pipe operator | (that is, __or__) to implement function<br>
composition, as demonstrated here:<br>
<br>
<a href="http://docs.astropy.org/en/stable/modeling/compound-models.html#model-composition" target="_blank">http://docs.astropy.org/en/stable/modeling/compound-models.html#model-composition</a><br>
<br>
I do like the idea of using the new @ operator for this purpose--it<br>
makes sense as a generalization of linear operators,<br>
and it just looks a little more like the circle operator often used<br>
for functional composition.  On the other hand<br>
I'm also fond of the choice to use |, for the similarity to UNIX shell<br>
pipe operations, as long as it can't be confused with<br>
__or__.  Point being something like this could be implemented now with __or__.<br>
<br>
I think this is simple enough that it doesn't need to be in the<br>
stdlib, especially if there are different ways people<br>
would like to do this.  But I do like the idea.<br>
<span class="HOEnZb"><font color="#888888"><br>
Erik<br>
</font></span></blockquote></div><br></div>