PEP309 - built-in curry class (revisions)

Peter Harris scav at
Sun Mar 2 23:41:42 CET 2003

Scott David Daniels <Scott.Daniels at Acm.Org> wrote in message news:<3e5fa164$1 at>...
> Peter Harris wrote:
> > Carl Banks <imbosol-1046365979 at> wrote in message news:<18s7a.35798$ep5.10090 at>...
> >>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.
OK, 2 independent seconds for that, it's going in the PEP.

> >>>   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"
Didn't think of that. Who is still supporting pre-2.2 python?

> 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).
Hmm. Someone please put in a PEP for dicts to get that method (maybe
dict.augment() ?) exposed in Python. ;)
> >>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.
Noted, but no reason to make it even less useful. I wouldn't use it
that way myself, but someone might want to.

> > 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.
Oh it's all kinds of bad idea. 

> 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?

Can open, worms everywhere. Not my worms, however. I'd probably
go for compose(f,g) == f(g(x,*args,**kw)), and f better just expect
one argument. If it takes more, curry them in ;) Like I said, it's
not really part of the PEP.
> -Scott David Daniels
> Scott.Daniels at Acm.Org

More information about the Python-list mailing list