[Twisted-Python] Advice sought on application evolution

[Matthew Glubb]

I'd like to elaborate, for my own benefit as much as anyone else ;)

On 21 Mar 2008, at 22:07, washort at twistedmatrix.com wrote:
> 1) Preserve the property that only code you can see locally referenced
>    can be executed (i.e., that in "step1(); step2()" only code called
>    by those two functions can be executed before the statement is
>    finished) and complicate the syntax in places where other code  
> needs
>    to be allowed to execute.

Or another way of saying it is that what is slightly dangerous about  
inlineCallbacks is you lose any benefits of parallelism you may have  
been enjoying because you want to make your code slightly more  
readable / writeable.

Consider the following:

@defer.deferredGenerator
def foo(self, d):
     for x in self.somelist:
         w = defer.waitForDeferred(x.bar())
         yield w
     d.callback(True)

Each successive call of x.bar must wait for the previous one to  
complete. Whereas in the following example x.bar() is called in  
parallel for each item in self.someList:

def foo(self):
     d = defer.Deferred()
     self._done_count = 0
     for x in self.somelist:
         x.bar().addCallback(self._done_bar, d)
     return d

def _done_bar(self, result, d):
     self._done_count = self._done_count + 1
     if self._done_count == len(self.somelist):
         d.callback(result)

IMHO, inline callbacks should only be employed when you can guarantee  
that sequential executions of each statement is exactly what you want  
to do. Readability / writeability comes second.


Matt