PEP 309 - Built-in closure type (with tentative syntax proposal)

[Carl Banks]

Peter Harris wrote:
> Carl Banks <imbosol-1045586581 at aerojockey.com> wrote in message news:<lKB2a.32074$F25.10142 at nwrddc02.gnilink.net>...
>> I hope you're aware that Python (staring from 2.1) already has
>> closures (and they're quickly becoming my favorite thing ever).  As
>> others have mentioned, what you're proposing is a built-in curry,
>> which is just a closure that calls a given function with given
>> arguments.
>> 
>> In fact, the better way to do the above (2.1+) is to use a real
>> closure (I'm surprised Martelli didn't point this out):
>> 
>>     from __future__ import nested_scopes
>> 
>>     def curry(fn,*cargs,**ckwargs):
>>         def call_fn(*fargs,**fkwargs):
>>             d = ckwargs.copy()
>>             d.update(fkwargs)
>>             return fn(*(cargs+fargs),**d)
>>         return call_fn
>> 
> Sweet. I was thinking more of a type though, so that you could sub-class
> it and do introspection on it. Maybe even pickle it. (Although what a
> pickled curry would taste like I shudder to imagine).

Ok.  Introspection of a curry would be of minor usefulness.  I can't
think of any good use for subclassing, though, and pickling is out of
the question.

The version using closures is a lot faster than the class version (my
tests indicated about 50% more time required for the class version).


Of course, an extension class written in C would be best.  I wrote a
currry module in C (doing it my way, of course) that was much faster
than the above curry written in Python.  I was hoping it would be
faster than a lambda, so that this:

    map(curryleft(operator.add,1),list)

would be faster than this:

    map(lambda x:x+1,list)

but it turned out to be a little slower.


> Overriding the keyword arguments is so useful, what's not to like
> about it?

It violates my conception of an invariant of a curry.  When you curry
a function, it is, to me, a guarantee that you'll call that function
with the arguments provided.  If you can override arguments, that
invariant no longer holds.  It might not concern you, but I don't like
it.


>> I would like to be able to curry arbitrary arguments.  Something like:
>> 
>>     curry(fn,__,arg,__)
>> 
>> where the __ parameters become arguments of the curried function.
>> Functions like curryleft could be special cases or something.
> 
> Now that is nearly as ugly as my brain-dead @ notation ;)

I don't agree.  The "ugliness" of your brain-dead @ notation wasn't
aesthetic, at least it wasn't to me.  To me, the ugliness was the
burden of a new syntax, and the relative uselessness of what it
accomplishes.

My proposal does not have this kind of ugliness, and works in the
general case.


-- 
CARL BANKS