Question

Is there any reason to use one over the other?

Do they have the same performance?

Answer 1

I tend to use inlineCallbacks for multistep initialization (such as auth) to some service where each subsequent step depends on a result from the previous step, for example. Other than these situations, I tend to find that inlineCallbacks could lead to lazy programming that could slow down your app.

Here’s an example:

@defer.inlineCallbacks
def some_func():
    res1 = yield call1()
    res2 = yield call2()
    ... do something with res1 and res2 ...

If call1 and call2 are completely independent calls that you want to parallelize, this function will end up serializing those calls. To convert this to a parallelizing call you should:

@defer.inlineCallbacks
def some_func_better():
    d1 = call1()
    d2 = call2()
    res1 = yield d1
    res2 = yield d2

This way you get call1 and call2 running simultaneously, but you wait on the results as they come in. So, while it’s possible to get the same benefits out of stock deferreds, it seems inlineCallbacks just make it too easy to implement the former solution.

Also, keep in mind that you still have to wrap try...except blocks around all your yield calls, as they’re the only way to trap errbacks within your code (unless a calling function of an inlineCallbacks function handles the errback at that level).

So, I find it’s not really a question of performance per se, but rather good habits that would make me recommend against inlineCallbacks in general – they’re still great for quick code snippets, multi-stage initialization routines, or tests for example.