[Python-ideas] (no subject)

[Ivan Levkivskyi]

Dear Andrew,

Thank you for pointing out the previous discussion, I have overlooked it.
(Btw, I have found your post about the infix operators, that is a great
idea).
Also, It turns out that astropy uses a very similar idea for function
composition.

I agree that there are indeed to much ambiguities about the "right way",
and thus it is not good for stdlib. However, implementing only one
decorator as a third-party library is not good idea as well.
You are right that no one will install such library. Probably, it would be
better to combine it with other functionality like @infix (via overloading
__or__ or __rshift__), @auto_curry, etc.

Thank you for the feedback!


On 6 May 2015 at 15:59, Andrew Barnert <abarnert at yahoo.com> wrote:

> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150506/f83dad2f/attachment.html>