[Twisted-Python] Some things I've learned: safer callbacks, better t.p.context

Itamar Turner-Trauring itamar at itamarst.org
Wed Oct 19 15:45:53 MDT 2016




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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20161019/4e461e8b/attachment-0002.html>


More information about the Twisted-Python mailing list