PEP309 - built-in curry class (revisions)

[Scott David Daniels]

Peter Harris wrote:
> Carl Banks <imbosol-1046365979 at aerojockey.com> wrote in message news:<18s7a.35798$ep5.10090 at nwrddc02.gnilink.net>...
>>Peter Harris wrote:
>>>How about the following?
>>>   Module to be called "functional" (it can be a home for
>>>   operations on higher-order functions in general.)
>>Good idea.

I agree as well.

>>>   functional.curry() as a nested function.

Seems fine where nested functions work.  I'd put this after the
class implementation, and include a comment roughly like:
     # for older pythons, use "curry = Curry"

>>>   functional.Curry as a class, so those who want the
>>>       introspection and sub-classing can have it.

> Well, not everything in the standard library is implemented in C. 
 > I can see the performance argument, but on the other hand there
 > is also the benefit of everyone being able to see the source.

Implementation in python should probably do.  Esp. for the first
few rounds of shake-out.  The one win I see is that C exposes a
reverse-sense dictionary update.  See if it can be used to change
the saved_dictionary.copy().update(final_dictionary) to something
like a final_dictionary.reversed_update(saved_dictionary).


>>As for the contents of the module, even if a general curry that can
>>pick and choose its arguments isn't a good idea, there should at least
>>be a right curry along with a left curry, so you can do things like
>>this (to return first item of a list):
>>
>>    curryright(operator.getitem,0)

I would argue that rightcurry would be a better name.  It is
closer to what you called it in your description above.  Note
(explicitly, in the doc) that rightcurry cannot accept keyword
parameters.

> If you wanted a general substitution like maybe:
>    g = curryinsert(f,a,__,b__,opt=1)
> ...
First, I want to be clear: I think a general inserter is a bad idea.
Second, a better form might be:
	curries(function, dictionary)
where dictionary keys which are integers indicate positional
args, and strings are keyword args.  Seems like a nasty mess to
me, however.  A specific composer for the form you want to fill
in (with an appropriately chosen name) would usually be better.

Functional composition is another good candidate, but figure
out what to do about multi-arg functions.  compose(f,g) is good,
but where do extra args to f go?  Further, if g returns a tuple,
does it become a single parameter to f or multiple parameters?

-Scott David Daniels
Scott.Daniels at Acm.Org