Alex Nanouu wrote: >though this might be a bit late, I would like to suggest something a >bit functionally different: >---cut--- >class LCurry(object): > ''' > 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[0] + args, func._curry_args[1]) > obj._curry_kw = kw = kw.copy() > kw.update(func._curry_kw) > else: > 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[0] + args + >self._curry_args[1], **dict(self._curry_kw.items() + kw.items())) > >--uncut-- > >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 make it. 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. Peter Harris
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4