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

[Jasper St. Pierre]

On Sun, Oct 14, 2012 at 2:17 PM, Guido van Rossum <guido at python.org> wrote:
> 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.

Of course, but that wouldn't be done at the Future level, but at the
fetch_async level. I just want to make sure that we're clear that the
Future itself isn't being registered with any event loop or reactor.

> --
> --Guido van Rossum (python.org/~guido)

-- 
  Jasper