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