[Twisted-Python] Advice sought on application evolution

[Phil Mayers]

> 
> In Python 2.5, I can say this more cleanly:
> 
> @defer.inlineCallbacks
> def frobulate():
>    step_1()
>    step_2()
>    step3Rslt = yield step_3_async()
>    step_4()
>    step_5()
>    returnValue(result5)
> 
> This is looking a lot better, but still the asynchrony of step_3 "shows 
> through".  (Again, I'm taking the viewpoint of someone trying to 
> understand, maintain, and extend the functionality of the application, 
> without having the asynchronous aspects "thrust in his face" more than 
> absolutely necessary.)
> 

The feeling amongst a lot of people, myself included, is that it's a 
*good* thing that the asynchronous nature shows. If you attempt to hide 
it, you forget the actual nature of the problem and start forgetting 
some fundamental problems that might occur.

A related example is Twisted's Perspective Broker - it explicitly has 
remoteref.callRemote('name', *args) semantics, so that callers are aware 
the errors returned could be any one of the network-related ones, as 
well as errors from the call itself.

> Of course, I can avoid all this by going to a threading or separate 
> process solution, but I'd like to find out if I'm missing something 
> before I make such a commitment.
> 
> Thanks for any good words,
>