[Twisted-Python] Advice sought on application evolution
zmola at acm.org
Wed Mar 26 09:30:09 EDT 2008
Justin Warren wrote:
> On Sun, 2008-03-23 at 03:48 +0000, glyph at divmod.com wrote:
>> On 22 Mar, 01:54 pm, mithrandi at mithrandi.net wrote:
>>> But yes, the danger of accidentally serializing operations that don't
>>> need to be serialized, and not even realising it, is one of the
>>> with this coding style.
>> As time goes on, I'm becoming a bigger fan of inlineCallbacks.
>> Too much serialization, even accidental serialization, trades
>> comprehensibility for performance. I think that's a reasonable place to
>> start: make your system easy to understand, then make it fast once you
>> know what's going on.
> How does the saying go? "Premature optimisation is the root of all
> As an intermediate novice, I find inlineCallbacks to be a great way to
> make code look more like sequential code, but with many of the benefits
> of asynchrony. You can then refactor the code to make pieces even more
> asynchronous where it's useful, but keep the sequential parts where that
> makes sense. This is great from a 'learning twisted' point of view.
My biggest reason for using frameworks like Twisted, is that they make
it easier to implement network applications.
Serial programming works well when the tasks are simple, and errors are
As soon as error/timeouts/corner cases are considered, your nice simple
serial code is more complex and much slower than the "more complex"
This is why people do not always see the immediate need for asynchronous
programming. If inline callbacks offer a way to ease yourself in to
Twisted, or make your program more understandable to others, then it is
BTW, maybe this workflow could be used for a Twisted presentation.
Take an existing program and turn it into a Twisted program.
zmola at acm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-Python