There are two minor niggles I frequently run into when writing code with
deferreds and callbacks:
1. I very often write callbacks that ignore the incoming result: I tend to
write this as def cb(_): ...
2. I sometimes write functions that I want to call both from within a
callback chain and when not in a callback chain. Usually this is
another case of writing def x(_, arg1, arg2) etc. and documenting that
the extra unused arg is for when the function is called as part of a
callback chain. This looks odder when the function is some kind of
utility living in different Python source file, and is thus distant
from its use in a callback chain.
Seeing as n-1 of the add* methods of t.i.defer.Deferred are convenience
methods for calling addCallbacks, I propose another:
def addCallback0(self, callback, *args, **kw):
self.addCallback(lambda result: callback(*args, **kw))
This allows you to write callback functions that will not be passed the
result of the callback chain. That means I never have to deal with 1 and 2
above. They're minor niggles, of course, but they make code look less
attractive and a little harder to understand. Yes, I could write my own
standalone function
def addCallback0(d, callback, *args, **kw):
d.addCallback(lambda result: callback(*args, **kw))
and pass it my deferreds. And yes, I can also write my own wrapper to call
other methods which don't take a callback result as their first argument.
But all this would be nicer if addCallback0 was part of the Deferred class.
I don't think we need a corresponding addBoth0 or addErrback0 etc., though.
Terry