This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients alex, collinwinter, eric.araujo, ezio.melotti, gregory_p, markonervo, pitrou, rhettinger, serprex
Date 2011-11-18.19:43:33
SpamBayes Score 2.4669341e-06
Marked as misclassified No
Message-id <1321645117.3352.4.camel@localhost.localdomain>
In-reply-to <1321645095.52.0.587027963.issue13430@psf.upfronthosting.co.za>
Content
> Sure, it's common `defining new functions on other functions`... more
> times. Here a stupid example with fold (our reduce).
> 
> @curry
> def fold(function, start, sequence):
>     if len(sequence) == 0:
>         return start
>     else:
>         return fold(function, function(start, sequence[0]), sequence[1:])
> 
> Now, someone could be define a generic summer function by fold.
> 
> import operator as op
> 
> summer = fold(op.add)

Right... so you defined these helper functions (curry, fold) just to...
define a generic summer function? Really?

I understand that fold() and curry() may look pretty to functional
languages people, but they don't solve any real-world problems that
Python doesn't already solve in a neater way. You will have to try a bit
harder and showcase examples of *useful* code that are made
significantly easier through the use of curry().

(no, generic summer functions are *not* real-world use cases. They are
homework exercises for CS students, at best)
History
Date User Action Args
2011-11-18 19:43:34pitrousetrecipients: + pitrou, collinwinter, rhettinger, gregory_p, ezio.melotti, eric.araujo, alex, serprex, markonervo
2011-11-18 19:43:33pitroulinkissue13430 messages
2011-11-18 19:43:33pitroucreate