On Sat, Oct 20, 2012 at 6:38 PM, Guido van Rossum <guido@python.org> wrote:
On Sat, Oct 20, 2012 at 12:25 PM, Jasper St. Pierre <jstpierre@mecheye.net> wrote:
I'm curious now... you keep mentioning Futures and Deferreds like they're two separate entities. What distinction between the two do you see?
They have different interfaces and you end up using them differently.
Who is "you" supposed to refer to?
In particular, quoting myself from another thread, here is how I use the terms:
- Future: something with roughly the interface but not necessarily the implementation of PEP 3148.
- Deferred: the Twisted Deferred class or something with very similar functionality (there are some in the JavaScript world).
The big difference between Futures and Deferreds is that Deferreds can easily be chains together to create multiple stages, and each callback is called with the value returned from the previous stage; also, Deferreds have separate callback chains for regular values and errors.
Chaining is an add-on to the system and not necessarily required. Dojo's Deferreds, modelled directly after Twisted's, don't have direct chaining with multiple callbacks per Deferred, but instead addCallback returns a new Deferred, which it may pass on to. This means that each Deferred has one result, and chaining is done slightly differently. The whole point of chaining is just convenience of mutating a value before it's passed to the caller. It's possible to live without it. Compare: from async_http_client import fetch_page from some_xml_library import parse_xml def fetch_xml(url): d = fetch_page(url) d.add_callback(parse_xml) return d with: def fetch_xml(url): def parse_page(result): d.callback(parse_xml(result)) d = Deferred() page = fetch_page(url) page.add_callback(parse_page) return d The two functions, treated as a black box, are equivalent. The distinction is convenience.
-- --Guido van Rossum (python.org/~guido)
-- Jasper