[Python-ideas] (no subject)

[Andrew Barnert]

This was discussed when the proposal to add @ for matrix multiplication came up, so you should first read that thread and make sure you have answers to all of the issues that came up before proposing it again.

Off the top of my head:

Python functions don't just take 1 parameter, they take any number of parameters, possibly including optional parameters, keyword-only, *args, **kwargs, etc. There are a dozen different compose implementations on PyPI and ActiveState that handle these differently. Which one is "right"?

The design you describe can be easily implemented as a third-party library. Why not do so, put it on PyPI, see if you get any traction and any ideas for improvement, and then suggest it for the stdlib?

The same thing is already doable today using a different operator--and, again, there are a dozen implementations. Why isn't anyone using them?

Thinking in terms of function composition requires a higher level of abstraction than thinking in terms of lambda expressions. That's one of the reasons people perceive Haskell to be a harder language to learn than Lisp or Python. Of course learning Haskell is rewarding--but being easy to learn is one of Python's major strengths.

Python doesn't have a static optimizing compiler that can avoid building 4 temporary function objects to evaluate (plot @ sorted @ sqrt @ real) (data_array), so it will make your code significantly less efficient.

Is @ for composition and () for application really sufficient to write point free code in general without auto-curried functions, operator sectioning, reverse compose, reverse apply, etc.? Most of the examples people use in describing the feature from Haskell have a (+ 1) or (== x) or take advantage of map-type functions being (a->b) -> ([a] -> [b]) instead of (a->b, [a]) -> [b].

Sent from my iPhone

> On May 6, 2015, at 06:15, Ivan Levkivskyi <levkivskyi at gmail.com> wrote:
> 
> Dear all,
> 
> The matrix multiplication operator @ is going to be introduced in Python 3.5 and I am thinking about the following idea:
> 
> The semantics of matrix multiplication is the composition of the corresponding linear transformations.
> A linear transformation is a particular example of a more general concept - functions.
> The latter are frequently composed with ("wrap") each other. For example:
> 
> plot(real(sqrt(data)))
> 
> However, it is not very readable in case of many wrapping layers. Therefore, it could be useful to employ
> the matrix multiplication operator @ for indication of function composition. This could be done by such (simplified) decorator:
> 
> class composable:
> 
>     def __init__(self, func):
>         self.func = func
> 
>     def __call__(self, arg):
>         return self.func(arg)
> 
>     def __matmul__(self, other):
>         def composition(*args, **kwargs):
>             return self.func(other(*args, **kwargs))
>         return composable(composition)
> 
> I think using such decorator with functions that are going to be deeply wrapped 
> could improve readability.
> You could compare (note that only the outermost function should be decorated):
> 
> plot(sorted(sqrt(real(data_array)))) vs. (plot @ sorted @ sqrt @ real) (data_array)
> 
> I think the latter is more readable, also compare
> 
> def sunique(lst):
>     return sorted(list(set(lst)))
> 
> vs. 
> 
> sunique = sorted @ list @ set
> 
> Apart from readability, there are following pros of the proposed decorator:
> 
> 1. Similar semantics as for matrix multiplication.
> 2. Same symbol for composition as for decorators.
> 3. The symbol @ resembles mathematical notation for function composition: ∘
> 
> I think it could be a good idea to add such a decorator to the stdlib functools module.
> _______________________________________________
> 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/