<div dir="ltr">Just for one mor eexample - I have a toy implementation here as well:<div><a href="https://github.com/jsbueno/chillicurry">https://github.com/jsbueno/chillicurry</a> <br></div><div>I decided to use the "." operator itself, and frame introspection to retrieve the function</div><div>to be called from the calling context - that is rude, I know.<br><br>But what I like of this approach is that by using the "." I have full control of the objects called as functions</div><div>on the chain - which allowed me to use a constant value that will be replaced by the "dynamic" parameter from </div><div>previous function calls.</div><div><br></div><div>So, if I want "max(len(mytext), 10)", I can write "curry.max(DELAY, 10).len(mytext)"   - the "max" call will only take place after len is evaluated. (And for functions wth a single parameter, there is no need for that)<br><br>Lessons learned: <br>1) One wanting curry can do so without changing Python Syntax</div><div>2) For control of functions that need more than one parameter, one needs a lazy-call mechanism.</div><div><br></div><div>Possibly the "lazy call" mechanism would be a more interesting "add on" to the language than currying per se. (It is</div><div>due to not being able to lazy call that I resort to the transforms using ".")</div><div><br></div><div>That said, if anyone like the the "chillicurry" approach enough that wants to help polishing it enough for pypi,</div><div> just get in touch.</div><div><br></div><div>   js</div><div>  -><-</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 January 2017 at 18:38, David Mertz <span dir="ltr"><<a href="mailto:mertz@gnosis.cx" target="_blank">mertz@gnosis.cx</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The `tools` (and `cytoolz` that has an identical API) provides an `@curry` decorator that is more general and elegant than the links earlier IMO.  Maybe I'm biased because I work with principal author Matt Rocklin, but toolz is really neat.<div><br></div><div>See: <a href="http://toolz.readthedocs.io/en/latest/curry.html" target="_blank">http://toolz.readthedocs.<wbr>io/en/latest/curry.html</a></div><div><br></div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Sun, Jan 29, 2017 at 3:08 AM, zmo via Python-ideas <span dir="ltr"><<a href="mailto:python-ideas@python.org" target="_blank">python-ideas@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">tl;dr: I agree with you, Steven, as proven by my former post, augmented<br>
with the details of your reply: there's no advantage to add a new<br>
operator and language construct for this use case.—<br>
<span><br>
On Sun, Jan 29, 2017 at 01:30:13PM +1100, Steven D'Aprano wrote:<br>
> On Sat, Jan 28, 2017 at 03:16:27PM +0100, zmo via Python-ideas wrote:<br>
</span><span>> > This idea sounds fun, so as a thought experiment why not imagine one<br>
> > way of integrating it in what I believe would be pythonic enough.<br>
<br>
> This idea is sometimes called "the Collection Pipeline" design pattern,<br>
> and is used in various command shells. Martin Fowler wrote about this<br>
> design pattern here:<br>
> <a href="https://martinfowler.com/articles/collection-pipeline/" rel="noreferrer" target="_blank">https://martinfowler.com/artic<wbr>les/collection-pipeline/</a><br>
> and I wrote a recipe for it:<br>
> <a href="https://code.activestate.com/recipes/580625-collection-pipeline-in-python/" rel="noreferrer" target="_blank">https://code.activestate.com/r<wbr>ecipes/580625-collection-pipel<wbr>ine-in-python/</a><br>
> with a working, although basic, implementation.<br>
</span><span>>     print(list(map(float, filter(lambda n: 20 < n < 30, data))))<br>
</span>> […]<br>
<span>>     data | Filter(lambda n: 20 < n < 30) | Map(float) | List | Print<br>
<br>
</span>It's indeed an interesting tip and idea, and using the pipe is not a bad<br>
idea as it's a good mnemonic for anyone who used a shell. About reading<br>
order, I'm personally agnostic.<br>
<span><br>
> (In principle, Python built-ins could support this sort of syntax so I<br>
> could write filter, map, list, print rather than custom versions Filter,<br>
</span>> Map, etc. […] But for Python that would be a *major* change, and not one I<br>
> wish to propose. […])<br>
<br>
Even as an external library, I would use that kind of syntax with<br>
extreme care in python. As a python developer, one of the things I<br>
really do enjoy is that any python code looks like a python code, and<br>
that's because changing meaning of operators depending on the context is<br>
discouraged.<br>
<br>
Then, unlike Scala, C++ or Ruby, you never end up with the language<br>
looking like a new DSL for each application or framework.<br>
<span><br>
> > On Sat, Jan 28, 2017 at 12:41:24PM +0000, Ed Kellett wrote:<br>
</span><span>> > So, considering it's decided that the RHS is in charge of filling up all<br>
> > the arguments of the LHS,<br>
> Is that actually decided?<br>
<br>
</span>it's not, it's part of the thought experiment of 'if we had such syntax',<br>
how could we handle arguments?<br>
<br>
> […] so either we have a new, parallel series of functions including<br>
<span>> Filter(...) or we write something like:<br>
>     print XYZ list XYZ map XYZ lambda (f1, f2, arg): (f1, filter(f2, arg))(float, lambda n: 20 < n < 30, data)<br>
> which is simply horrid. Maybe there could be a series of helper<br>
</span>> functions, but I don't think this idea is workable. […]<br>
<br>
> > […]<br>
<span>> > All in all, it can be a nice syntactic sugar to have which could make it<br>
> > more flexible working with higher order functions, but it with the way<br>
> > I'm suggesting to comply with python's arguments handling, it offers<br>
> > little advantages when the RHS is not filling LHS arguments:<br>
</span>> > […]<br>
<span>> I think that "literal advantage" is being very kind. The best you can<br>
> say is that you save two pairs of parentheses at the cost of three<br>
> operators and moving arguments away from the functions that use them.<br>
<br>
</span>I said "little" not "literal" ☺ I started the whole reasoning trying to<br>
be objective and figure how such a new syntax would be integrated in<br>
python and what good use could be made of it. And in the end, I end up<br>
with something that can offer a nice syntax for a very niche case, and<br>
wouldn't be of much use most of the time.<br>
<br>
The fact that it can be implemented with some operator overload, as you<br>
nicely demonstrated just proves the fact further: this is not a good<br>
idea.<br>
<span><br>
> [...]<br>
> > But then it would be just another way to introduce currying as a<br>
> > language feature with an operator, so we should then just discuss on how<br>
> > to add currying as a language syntax "by the book", but I'm pretty sure<br>
> > that's a topic already discussed before I joined this list ;-)<br>
> The easiest way to support currying, or at least some form of it, is:<br>
>     from functools import partial as p<br>
>     p(map, float)  # curries map with a single argument float<br>
> which is not quite the map(float) syntax Haskell programmers expect,<br>
> but its not awful.<br>
<br>
</span>Indeed, I love having that available as a function! We could reopen the<br>
debate as to whether we should implement currying into python, but since<br>
my last post I've done a bit of searching, and found out it's been<br>
discussed 14 years ago:<br>
<br>
<a href="https://mail.python.org/pipermail/python-dev/2004-February/042668.html" rel="noreferrer" target="_blank">https://mail.python.org/piperm<wbr>ail/python-dev/2004-February/<wbr>042668.html</a><br>
<a href="https://www.python.org/dev/peps/pep-0309/" rel="noreferrer" target="_blank">https://www.python.org/dev/pep<wbr>s/pep-0309/</a><br>
<br>
and a few discussions, implementations of (real) currying published more<br>
recently:<br>
<br>
<a href="https://mtomassoli.wordpress.com/2012/03/18/currying-in-python/" rel="noreferrer" target="_blank">https://mtomassoli.wordpress.c<wbr>om/2012/03/18/currying-in-pyth<wbr>on/</a><br>
<a href="http://code.activestate.com/recipes/577928-indefinite-currying-decorator-with-greedy-call-and/" rel="noreferrer" target="_blank">http://code.activestate.com/re<wbr>cipes/577928-indefinite-curryi<wbr>ng-decorator-with-greedy-call-<wbr>and/</a><br>
<a href="https://gist.github.com/JulienPalard/021f1c7332507d6a494b" rel="noreferrer" target="_blank">https://gist.github.com/Julien<wbr>Palard/021f1c7332507d6a494b</a><br>
<br>
I could argue that a nicer syntactic sugar and having it as a language<br>
feature could help in having it supported in a more optimised fashion,<br>
instead of using an added layer of abstraction. But, I won't ^^<br>
<br>
Cheers,<br>
<span class="m_-7662563888394945781HOEnZb"><font color="#888888"><br>
--<br>
zmo<br>
</font></span><div class="m_-7662563888394945781HOEnZb"><div class="m_-7662563888394945781h5">______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a></div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-7662563888394945781gmail_signature" data-smartmail="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons.  Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br></blockquote></div><br></div>