Alex Nanouu wrote:
>though this might be a bit late, I would like to suggest something a
>bit functionally different:
> this is the left curry class.
> def __new__(cls, func, *args, **kw):
> obj = object.__new__(cls)
> if isinstance(func, LCurry) or isinstance(func, RCurry):
> obj._curry_func = func._curry_func
> obj._curry_args = (func._curry_args + args, func._curry_args)
> obj._curry_kw = kw = kw.copy()
> obj._curry_func = func
> obj._curry_args = (args, ())
> obj._curry_kw = kw.copy()
> return obj
> def __call__(self, *args, **kw):
> self._curry_func(*self._curry_args + args +
>self._curry_args, **dict(self._curry_kw.items() + kw.items()))
>this mainly has one thing different from the reference implementation
>in the pep:
>1) it is recursive
>that is we can curry/partial something more than one and yet avoid the
>extra function call per curry level...
>IMO this is a worthwhile optimisation....
I think we'll see if partial() is a useful enough feature to be worth optimising once it
actually makes it into a build and gets used.
Mostly I think nesting many layers of partial(), or optimising the implementation with
that in mind will not be a win for clarity, therefore a net loss however fast you can
By the way, I think 'right curry' is just a broken idea from the point of view of code readability. (I know the n'th argument is '2', but 'n' will depend on how many arguments are passed at run time!) The PEP doesn't propose to implement such a monster, or call partial() a curry at all, let alone a 'left' one.