[Twisted-Python] Advice sought on application evolution

glyph at divmod.com glyph at divmod.com
Sun Mar 23 19:14:55 EDT 2008


On 11:06 am, p.mayers at imperial.ac.uk wrote:
>>
>>It's great as a high-level prototyping tool and an orchestration 
>>language for distributed conversations with large numbers of steps and 
>>coarse- grained error handling.  It's bad as a way of representing 
>>state machines or continuous processes.
>
>Why?

Here's something which we probably should have done with a state 
machine, but instead did with deferredGenerator (the predecessor to 
inlineCallbacks).

http://divmod.org/trac/browser/trunk/Quotient/xquotient/grabber.py#L438

The function's really long, and there's a ton of duplication between all 
of the "except" clauses, and there needs to be a try/except around every 
single deferred call.  This probably would have been better implemented 
as a regular state-machine, because that would have allowed decomposing 
the problem further.

Granted, you could blame the factoring here on any number of things.  It 
could have been broken into different steps even with deferredGenerator, 
it could have been documented better, it could have stored more state on 
the instance so that you could inspect its state rather than hiding it 
as local variables... but given that this is general stylistic advice I 
think that the point holds.




More information about the Twisted-Python mailing list