[Twisted-Python] question about deferred lists tutorial description
Hi, I have been using twisted intermittently for a couple of months, but still don't feel like I have a good intuitive understanding of how to get things done quickly, and efficiently with the framework. Thus I've been revisiting the tutorial documents and resolved to go through them with a fine-toothed comb in an effort to really get my noggin around things. In the deffered discussion: http://twistedmatrix.com/projects/core/documentation/howto/defer.html there is a section about defer.DeferredList, which contains code examples and a subsequent note which -seems- to contradict the code above it: ------------begin code from tutorial---------- The callback will be called with a list of the results of the Deferreds it contains, like so: def printResult(result): print result deferred1 = defer.Deferred() deferred2 = defer.Deferred() deferred3 = defer.Deferred() dl = defer.DeferredList([deferred1, deferred2, deferred3]) dl.addCallback(printResult) deferred1.callback('one') deferred2.errback('bang!') deferred3.callback('three') # At this point, dl will fire its callback, printing: # [(1, 'one'), (0, 'bang!'), (1, 'three')] # (note that defer.SUCCESS == 1, and defer.FAILURE == 0) ------------end code from tutorial---------- Ok, so far, so good. You can build a series of deferreds, stick them in a DeferredList, add a callback to the list, *subsequently* add some callbacks/errbacks to the individual deferreds in the DeferredList, fire things up, and have the results of the *subsequently added* callbacks/errbacks sent to the DeferredList callback and printed out. However, the following Note regarding callbacks for DeferredList objects seems to contradict the promised results of the above codeblock, stating that: """If you want to apply callbacks to the individual Deferreds that go into the DeferredList, you should be careful about when those callbacks are added. The act of adding a Deferred to a DeferredList inserts a callback into that Deferred (when that callback is run, it checks to see if the DeferredList has been completed yet). The important thing to remember is that it is this callback which records the value that goes into the result list handed to the DeferredList's callback. Therefore, if you add a callback to the Deferred after adding the Deferred to the DeferredList, the value returned by that callback will not be given to the DeferredList's callback. To avoid confusion, we recommend not adding callbacks to a Deferred once it has been used in a DeferredList.""" Ok, so in fact, any callbacks/errbacks I need to add to deferreds which will be added to a DeferredList object, need to be added Prior to my adding the individual deferreds to the DeferredList object. Or so it would appear to my limited understanding. I would greatly appreciate it if someone could resolve this apparent contradiction for me, or if it is a mistake in the documentation, please point out which one of the code block or the note is actually correct. Cheers!
Apologies for the previous premature email; it seems I cannot read. The apparent contradiction I mentioned was the result of my conflating 'callback' with 'addCallback'. However, I guess I'd still appreciate some discussion on the nuances of these two functions. Cheers 2008/3/12, Josef Novak <josef.robert.novak@gmail.com>:
Hi, I have been using twisted intermittently for a couple of months, but still don't feel like I have a good intuitive understanding of how to get things done quickly, and efficiently with the framework. Thus I've been revisiting the tutorial documents and resolved to go through them with a fine-toothed comb in an effort to really get my noggin around things. In the deffered discussion: http://twistedmatrix.com/projects/core/documentation/howto/defer.html
there is a section about defer.DeferredList, which contains code examples and a subsequent note which -seems- to contradict the code above it:
------------begin code from tutorial---------- The callback will be called with a list of the results of the Deferreds it contains, like so:
def printResult(result): print result deferred1 = defer.Deferred() deferred2 = defer.Deferred() deferred3 = defer.Deferred() dl = defer.DeferredList([deferred1, deferred2, deferred3]) dl.addCallback(printResult) deferred1.callback('one') deferred2.errback('bang!') deferred3.callback('three') # At this point, dl will fire its callback, printing: # [(1, 'one'), (0, 'bang!'), (1, 'three')] # (note that defer.SUCCESS == 1, and defer.FAILURE == 0) ------------end code from tutorial----------
Ok, so far, so good. You can build a series of deferreds, stick them in a DeferredList, add a callback to the list, *subsequently* add some callbacks/errbacks to the individual deferreds in the DeferredList, fire things up, and have the results of the *subsequently added* callbacks/errbacks sent to the DeferredList callback and printed out.
However, the following Note regarding callbacks for DeferredList objects seems to contradict the promised results of the above codeblock, stating that:
"""If you want to apply callbacks to the individual Deferreds that go into the DeferredList, you should be careful about when those callbacks are added. The act of adding a Deferred to a DeferredList inserts a callback into that Deferred (when that callback is run, it checks to see if the DeferredList has been completed yet). The important thing to remember is that it is this callback which records the value that goes into the result list handed to the DeferredList's callback.
Therefore, if you add a callback to the Deferred after adding the Deferred to the DeferredList, the value returned by that callback will not be given to the DeferredList's callback. To avoid confusion, we recommend not adding callbacks to a Deferred once it has been used in a DeferredList."""
Ok, so in fact, any callbacks/errbacks I need to add to deferreds which will be added to a DeferredList object, need to be added Prior to my adding the individual deferreds to the DeferredList object. Or so it would appear to my limited understanding.
I would greatly appreciate it if someone could resolve this apparent contradiction for me, or if it is a mistake in the documentation, please point out which one of the code block or the note is actually correct.
Cheers!
participants (1)
-
Josef Novak