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

[Ben Darnell]

On Fri, Oct 12, 2012 at 4:39 PM, Richard Oudkerk <shibturn at gmail.com> wrote:
>>   @task
>>   def view_paste_async(request, filekey):
>>      # Create Futures -- no yields!
>>      f1 = Pastes.objects.get_async(key=filekey) # This won't raise
>>      f2 = loader.get_template_async('pastebin/error.html')
>>      f3 = loader.get_template_async('pastebin/paste.html')
>>
>>      try:
>>          fileinfo= yield f1
>>      except DoesNotExist:
>>          t = yield f2
>>          return HttpResponse(t.render(Context(dict(error='File does not
>> exist'))))
>>
>>      f = yield open_async(fileinfo.filename)
>>      fcontents = yield f.read_async()
>>      t = yield f3
>>      return HttpResponse(t.render(Context(dict(file=fcontents))))
>
>
> So would the futures be registered with the reactor as soon as they are
> created, or only when they are yielded?  I can't see how there can be any
> "concurrency" if they don't start till they are yielded.  It would be like
> doing

The Futures are not what is doing the work here, they just hold the
result.  In this example the get_async() functions register something
with the reactor when they are called.  When that "something" is done
(or perhaps after several "somethings" chained together), get_async
will set a result on its Future.

> But if the futures are registered immediately with the reactor then does
> that mean there is a singleton reactor?  That seems rather inflexible.

In most event-driven systems there is a global (or thread-local) event
loop, but it's also possible to pass one in explicitly to get_async().

-Ben