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

[Laurens Van Houtven]

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?

2) doing multiple things concurrently. Let's say I want to download 10 web
pages and do something when all ten of them have completed. In twisted, I
can say:

gatherResults(map(getPage, urls)).addCallback(...)

with inlineCallbacks, you can do quite similar things (just yield the
result of gatherResults, since that's a deferred that'll fire once all of
them have fired):

for body in (yield gatherResults(map(getPage, urls)):
    ....

---

How would these two look in a world where the generator/inlineCallbacks
magic isn't generator backed?

cheers
lvh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121013/f0191a16/attachment.html>