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

[Nick Coghlan]

On Sat, Oct 13, 2012 at 9:05 PM, Laurens Van Houtven <_ at lvh.cc> wrote:
> In addition to the issue mentioned by Itamar, there needs to be a clear way
> to do two related things:
>
> 1) actually doing things asynchronously! A good example of where this
> happens for me is stats logging. I log some stats, but I don't want to wait
> for the request to be completed before I continue on with my work:
>
> def callback():
>     logSomeStats()
>     return actuallyDoWorkCustomerCaresAbout()
>
> logSomeStats returns a deferred, and I probably would attach an errback to
> that deferred, but I don't want to wait until I've finished logging some
> stats to do the rest of the work, and I CERTAINLY don't want the work the
> customer cares about to bomb out because my stats server is down.
>
> In current inlineCallbacks, this is equally simple: I just run the
> expression and *not* yield. If I understand the current alternative
> suggestions correctly, the yielding part is important for actually hooking
> up the IO (whereas in @inlineCallbacks, it *only* does callback management).
> Perhaps I am mistaken in this belief?

Some have certainly suggested that, but not Guido. In Guido's API, the
*_async() calls actually kick off the operations, the "yield" calls
are the "I'm done for now, wake me when this Future I'm yielding is
ready".

This is the only way that makes sense, for the reasons you give here.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia