Well, partial + apply seems like the most powerful solution (supports
**keywords, opens up the possibility of using apply in other ways). Perhaps
adding apply back to functools rather than as a builtin would evade some of
the antipatterns it used to encourage (a la reduce). I'm not sure and don't
have a strong opinion about the original removal of apply.
Alternatively a form of "starcaller" or "unpackcaller" defined roughly as
partial(apply) could be added to the operator module in the capacity I
proposed above. The only possible advantage here is aesthetic; it fits
conceptually with the rest of the module as a callable capturing a
repeatable operation that is normally only possible with special syntax. It
also disallows using apply in "non-curried" contexts.
Thanks,
Dan
PS.
Emanuel, my use case is one where I am creating data transformations by
composing chains of function calls. The functions are executed in parallel
across multiple processes. Specifically I'm using the Dask Distributed
https://distributed.readthedocs.io/en/latest/ library.
On Thu, Jul 21, 2016 at 11:51 AM Emanuel Barry
From: Nick Coghlan Sent: Thursday, July 21, 2016 11:21 AM
On 22 July 2016 at 00:19, Emanuel Barry
wrote: Hello,
You’re presumably doing something like ‘star = starcaller(f); star((“foo”, “bar”, “baz”))’ – how is it different from ‘f(*(“foo”, “bar”, “baz”))’ ? I don’t see any difference…
Similar to functools.partial, it lets you more easily separate the process of changing a function's signature from actually calling it.
Compare:
def f(a, b): print(a, b)
accepts_only_b = functools.partial(f, "predefined_a") accepts_args_as_tuple = operator.starcaller(f)
Ah, of course - I didn't think of the multiple arguments case, thanks :)
-Emanuel