Deferreds in Twisted make it easy to chain asynchronous code with error handling together:

    def parseData(data):
        return doManyFancyThingsWith(data)
    
    def parsedAsyncResult():
        return asyncResult().addCallback(parseData)

    def callback(data):
        print 'Parsed data:', data
    def errback(err):
        print 'Oh no, something went wrong!'
    parsedAsyncResult().addCallbacks(callback, errback)

If an error is raised by either asyncResult() or parseData(), it will be caught by the errback function, even though parsedAsyncResult() didn't explicitly do anything to pass errors along.

That looks like an unnecessarily confusing way of writing this code:

    try:
        data = doManyFancyThingsWith(asyncResult())
        print 'Parsed data:', data
    except:
        print 'Oh no, something went wrong!'

That's the code I would write if I were using Eventlet or Gevent, and it would work just fine. Why settle for less? It's 2012, damn it; we shouldn't have to dick around with deferreds except under exotic circumstances.

This is possible in Twisted, using inline callbacks:

  try:
      data = doManyFancyThingsWith(yield asyncResult())
      print 'Parsed data:', data
  except:
      print 'Oh no, something went wrong!'

I find that I use inline callbacks for the common case and work with deferreds directly only when it makes more sense to handle callbacks explicitly.

I don't know, I find this quite readable:

  foo.doSomethingAsync(function(result) {
    ...
  }, {
  error: function(err) {
    ...
  },
  afterward: function(then) {
    ...
  },
  evenLater: function(wat) {
    ...
  }});

Which is not meant in any way to imply that there's nothing better :) Just that I see no reason to make the comparison to an abnormally-bad version.

When would the "evenLater" callback be called?

Besides, that's still only one function call. When you need to call many async things one after the other (that's what i meant by "chaining"), that nested callback-based code becomes much much convoluted than the analogous "normal" return-based code.

With promise monads [1] or some sort of language transformation that lets you write code that looks sequential but then is transformed into chained callbacks, you can basically get rid of all those extra callback functions and their associated complexity (i.e. all the mangled "success" and "error" callbacks from chained async functions) and have code that looks normal function calls one after the other. Notice that pufuwozu's example had three consecutive async calls, but it didn't need to create all the callback functions to pass between the calls.

[1]: This is a nice little spec for chainable promises: http://wiki.commonjs.org/wiki/Promises/A. And here's a post that explains how they are used: https://gist.github.com/3889970