In addition to the issue mentioned by Itamar, there needs to be a clear way to do two related things:<br><br>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:<br>

<br>def callback():<br>    logSomeStats()<br>    return actuallyDoWorkCustomerCaresAbout()<br><br>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.<br>

<br>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?<br>

<br>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:<br><br>gatherResults(map(getPage, urls)).addCallback(...)<br>

<br>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):<br><br>for body in (yield gatherResults(map(getPage, urls)):<br>

    ....<br><br>---<br><br>How would these two look in a world where the generator/inlineCallbacks magic isn't generator backed?<br><br>cheers<br>lvh<br><br>