On Tue, Oct 18, 2016, at 03:44 PM, Glyph Lefkowitz wrote: > > I think Deferred as it is today is a pretty good compromise between > the two positions. On the one hand it is decoupled from the event > loop. On the other - and this is important - *no Deferred-returning > API will ever call your callbacks synchronously*. > Deferred.addCallback will, of course, but savvy Twisted programmers > can (and should) do this, if they have dependent state changes: > >> self.manipulateSomeStateForSetup() >> >> d = doSomethingPotentiallySynchronous() >> *self.manipulateSomeStateForProcessing()* >> d.addCallback(completeOperation) > > As a caller, you can always decide whether you can safely be re- > entered or not. In most cases, simply moving the 'addCallback' to the > end of the function (a-la Go's "defer", oddly enough) is fine. In > more complex cases where you really need to unwind reentrancy > completely, you can do your own callLater(0) or callFromThread() from > an object with a reference to a reactor. Well... I had a test that went through synchronous Deferred path. And yeah, it was easier to write than async test. But it failed to catch a bug that was only in async case. So the problem I see is that supporting both in Deferred means you need twice the number of tests each time you use Deferreds. >> 3. > > What happened to '2'? :) There were only two points :)
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
