Function currying extension module

[Raymond Hettinger]

[Carl Banks]
> Inspired by PEP 309 (yet very different from it), I wrote a C
> extension class to perform function currying.  I'm hoping this could
> evolve into part of a module "functional" to appear in Python 2.4.
>
> Basic usage is g = curry(f,__,arg,__), whence g(1,2) results in f
> being called as f(1,arg,2).  curryleft and curryright also exist.
>
> Below are two python files, currytest.py and currydemo.py, followed by
> the source to the extension module, curry.c.  For me, currytest
> indicates that a simple lambda is still a little faster than the
> curry.

You should *always* be able to get the C implementation to run at least
a little faster.


> Opinion, comments, suggestions on how to make it faster?  It appears
> that the bottleneck is allocating a tuple, which not much can be done
> about.

The tuple allocation can be avoided by re-using the
same tuple over and over.  For a safe, fast implementation look in
CVS for the izip() function in the new itertools module.

You are also losing a few cycles in the parsing of "OOOO" in
PyObject_CallFunction.  Instead, try PyObject_CallFunctionObjArgs.

The use of the slot objects also adds a cost that is not in a pure
lambda version.  Here, you're paying a price for full generality.
A simple curry (without keywords or positional control) would
require much less code, be more readily learnable, and run faster:

>>> add1 = curry(operator.add, 1)
>>> add1(10)
11


Raymond Hettinger