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 _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python