[Twisted-Python] Advice sought on application evolution
glyph at divmod.com
glyph at divmod.com
Sun Mar 23 17:14:55 MDT 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