[stdlib-sig] futures and deferreds
brian at sweetapp.com
Sat Nov 7 23:33:02 CET 2009
On 8 Nov 2009, at 02:33, Antoine Pitrou wrote:
>> They do seem specialized for continuation-passing style programming
>> though. As far as I can tell from the docs (http://python.net/crew/mwh/apidocs/twisted.internet.defer.Deferred.html
>> ), the only way to process the results of a Deferred is my installing
>> a callback.
> Yes, but the last callback in the chain could trigger an Event, a
> or any other synchronization object to which you could wait on, if you
> want something "synchronous" (despite the title of your original
> message: "asynchronous execution" :-)).
Touché ;-) But I was actually indenting this to be used for
applications that are organized for synchronous but need some extra
performance for a few method calls.
>> with ThreadedDeferredMaker(max_threads=5) as dm
>> deferreds = 
>> for url in URLS:
>> deferred = dm.defer(load_url, url)
>> deferred. addCallbacks(print_success, print_failure, url=url)
> If you have a bunch of deferreds and want your callback to trigger
> all deferreds are finished/failed, you can use a DeferredList. A
> DeferredList is itself a Deferred so you can add callbacks to it
> (including one which makes things synchronous as explained above).
> (note that, as the doc says, "that you can still use a Deferred after
> putting it in a DeferredList". That is, you can react individually to
> each result to implement e.g. a progress indicator, and also react to
> the completion of all deferreds)
That's cool. A hybrid approach that allows you to use both callbacks
and inspection might make sense.
> Of course an all-synchronous API is still simpler to use for the use
> cases it is meant for.
> stdlib-sig mailing list
> stdlib-sig at python.org
More information about the stdlib-sig