...

...

...

...

"glyph" == glyph <glyph@divmod.com> writes: glyph> I don't believe there's been any extensive profiling of glyph> inlineCallbacks. At least, none that I'm aware of. I think what glyph> you are remembering is that inlineCallbacks generally results in an glyph> (often implicit, sometimes unintentional) loss of parallelism.

Yes, it's possible that the person I heard from informally was thinking of this of had heard something along these lines, etc. It's funny, Esteve and I were talking about code like your example just a few days ago. You have to know what you're doing. I agree the best/simplest example is where you have some form of loop and you should use a DeferredList, else you're implicitly serializing things that could be launched virtually all at once and finishing in any order at all. I'm interested not in those cases though, but in whether there's some mechanical (due to Python) advantage to one style of coding versus another. I might play a little more. I was going to write some code to generate different varieties of behaviorally-equivalent but differently structured code. In fact I think it wouldn't be hard to write something that could write your code for you in a variety of ways. E.g., you could write pseudo-code like a = A() if a < 45: b = B() c = a + b.hey() - C() if c: return D(12, c) else: return E() return F(a) and something digs through this code, figures out (maybe via a decorator used on functions returning a deferred - ugh, but it's just one suggestion) which of A, B, C, D and E return deferreds and spits out code to handle things for you. I could say more, but I'm sure no-one would reply :-) Thanks! Terry