[Python-ideas] Partial operator (and 'third-party methods' and 'piping') [was Re: Function composition (was no subject)]

[Andrew Barnert]

On Monday, May 11, 2015 10:46 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 5/11/2015 10:41 AM, Guido van Rossum wrote:
>>  As long as I'm "in charge" the chances of this (or anything 
> like it)
>>  being accepted into Python are zero.
> 
> I have been waiting for this response (which I agree with).
> By 'this', I presume you mean either more new syntax other than 
> '@', or 
> official support of '@' other than for matrix or array multiplication.

I don't think it's worth trying to push for this directly in Python, even with the @ operator or a functools.compose function, even if someone thinks they've solved all the problems. If anyone really wants this feature, the obvious thing to do at this point is to prepare a NumPy-wrapper library that adds __matmul__ and __rmatmul__ to ufuncs, and some examples, convince the NumPy team to accept it, and then, once it becomes idiomatic in NumPy code, come back to python-ideas. Maybe there is nothing about function composition which inherently requires broadcast-style operations to make it useful, but the only decent examples anyone's come up with in this thread (root-mean-square) all do, which has to mean something. And the NumPy core devs haven't explicitly announced that they don't want to be convinced.


>>  I get a headache when I try to

>>  understand code that uses function composition,
> 
> Function composition is the *process* of using the output of one 
> function (broadly speaking) as the input (or one of the inputs) of 
> another function.  All python code does this.  The discussion is about 
> adding a composition operator or function or notation (and 
> accoutrements) as a duplicate *syntax* for expressing composition.  As I 
> posted before, mathematician's usually define the operator in terms of 
> call syntax, which can also express composition.
> 
>>  and I end up having to
>>  laboriously rewrite it using more traditional call notation before I
>>  move on to understanding what it actually does.
> 
> Mathematicians do rewrites also ;-).
> The proof of (f @ g) @ h = f @ (g @ h) (associativity) is that
> ((f @ g) @ h)(x) and (f @ (g @ h))(x) can both be rewritten as
> f(g(h(x))).
> 
>>  I understand that it's fun to try to sole this puzzle, but evolving
>>  Python is more than solving puzzles.
> 
> Leaving aside the problem of stack overflow, one can rewrite "for x in 
> iterable: process x" to perform the same computational process with 
> recursive syntax (using iter and next and catching StopIteration).  But 
> one would have to be really stuck on the recursive syntax, as opposed to 
> the inductive process, to use it in practice.
> 
> -- 
> Terry Jan Reedy
> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>