Home Original page

[Python-ideas] The async API of the future: Twisted and Deferreds

Guido van Rossum guido at python.org
Sun Oct 14 20:17:51 CEST 2012 
On Sun, Oct 14, 2012 at 10:55 AM, Jasper St. Pierre
<jstpierre at mecheye.net> wrote:
> (Sorry if this is in the wrong place, I'm joining the conversation and
> I'm not sure where mailman will put it)
>
>> Alternatively, yielding a future (or whatever ones calls the objects
>> returned by *_async()) could register *and* wait for the result.  To
>> register without waiting one would yield a wrapper for the future.  So
>> one could write
>
> What would registering a Future do? As far as I understood it, the
> plan here is that a Future was just a marker for an outstanding
> request:
>
>     def callback(result):
>         print "The result was", result
>
>     def say_hello(name):
>         f = Future()
>         f.resolve("Hello, %s!")
>         return f
>
>     f = say_hello("Jeff")
>     f.add_callback(callback)
>
> The outstanding request doesn't have to care about socket connections;
> it's just a way to pass around a result that hasn't arrived yet. This
> is pretty much the same as Deferreds/Promises, with a different name.
> There's no reactor here to register here, because there doesn't need
> to be one.

The Future class itself probably shouldn't interface with the event
loop. But an operation that creates and returns a Future certainly
can.

-- 
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas mailing list