PEP309 - built-in curry class (revisions)
scav at blueyonder.co.uk
Sun Mar 2 23:41:42 CET 2003
Scott David Daniels <Scott.Daniels at Acm.Org> wrote in message news:<3e5fa164$1 at nntp0.pdx.net>...
> 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.
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
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