[Twisted-Python] A kinder and more consistent defer.inlineCallbacks

[Terry Jones]

Here's another way of looking at what I proposed.

When you call a function, you can divide what happens into 3 possibilities:

 1) An exception is raised
 2) You get back a generator
 3) You get back something else

(Yes, I'm ignoring aborts, sys.exit, etc).


As it stands, all three of these are handled inside _inlineCallbacks (not
in inlineCallbacks). With the code I suggested, the call to f is made
before _inlineCallbacks is called. Only in case 2, where we actually have a
generator, do we ask _inlineCallbacks to deal with unwinding it. In case 1
we pass the exception back via a deferred errback with a failure and in
case 2 we pass the result back in a deferred whose callback is already
called.  There's a good case (perhaps a stronger one) for just letting the
Exception go on its merry way and raise back in the calling code. But it's
hard to argue that knowing that we don't even have a generator result that
passing it on to _inlineCallbacks in the knowledge that it's going to
cryptically raise is better than just returning the result of the user's
function, especially seeing as it has just successfully run to completion!

Terry