This API is more or less constrained (== copied from) the same API in concurrent.futures and I don't think it is a big deal to have to work around it. (The Tulip philosophy is roughly "if you find yourself adding callbacks to futures, you're either writing a framework or doing it wrong" :-)
I usually prefer lambdas for this kind of adaptation, but in your example (where the callback is added in a loop and one of the parameters varies over the loop) you actually have to use functools.partial() to avoid the late binding of that variable. On Mon, Jan 6, 2014 at 3:42 AM, Tobias Oberstein <[email protected]> wrote: > Am 06.01.2014 14:31, schrieb Victor Stinner: > >> You can use partial.functools(), example: >> >>>>> def f(*args, **kw): print(args, kw) >> >> ... >>>>> >>>>> import functools >>>>> g = functools.partial(f, 1, 2, 3, key='value') >>>>> >>>>> g() >> >> ((1, 2, 3), {'key': 'value'}) >> >> Victor >> > > Sure, that works. But while currying might be intellectually exciting, it > makes the code even more verbose. > > And it might negatively effect performance .. it'll produce lots of short > lived functions under the hood, or not? > > /Tobias -- --Guido van Rossum (python.org/~guido)
