[Twisted-Python] Evangelism notes...
Mike C. Fletcher
mcfletch at rogers.com
Wed May 4 16:08:12 EDT 2005
As some of you know, I use Twisted to develop one of our products, a
fairly large Cable modem management application. I've developed and
released TwistedSNMP, and am, generally speaking comfortable with the
package. I've also been using Twisted within the company for my other
projects. I've just come back from a meeting where a decision was made
to completely rewrite a *delivered* application on our own dime for the
sole purpose of eliminating Twisted.
I found this rather disappointing.
I realise that the problem lay in part in my own "choice" (didn't
actually choose, it just happened) of projects with which to introduce
Twisted, but I felt it would be useful to share the experience with others.
* Cross-protocol server intended to act as a "web services"
intermediary for payment-processing services from a number of
different banking systems.
o Fairly straightforward networking protocols on all sides
o All protocols were custom (i.e. we had to write them) save
the client-side interface (which was XMLRPC)
o Seems like a perfect problem domain for Twisted
* Initially coded using Twisted by me, then pair programming with a
colleague as he took over lead on the project
o If my goal had initially been to evangelise, I should have
*started* the project with pair programming so that the
system wasn't already in-place and mystifyingly complex
+ Even the Finger sample is mystifyingly complex if you
jump into it at the end of the process
+ Unfortunately, I didn't realise the project would be
passed on to someone else before completion, I'd
thought it would remain part of my portfolio within
+ Even if we did start out together, we really should
have done some *formal* training on Twisted, rather
than relying on knowledge transfer via pair
programming. Again, it started out just being a few
lines here and there, we didn't see much being done
beyond the base system.
o He never, in the entire process, saw anything really come
from Twisted (other than problems where the complexity of
the system got in the way of doing the rather simple task
(from his point of view)), since the low-level coding was
already done when he started working with the system.
+ Probably would have been better to start him on the
much larger project, where Twisted represents far less
of the overall complexity of the application.
o In particular, test-driven development with threading in the
background for blocking operations caused significant headaches
* Project was delivered, paid for, and has been running in
production for a few weeks, but 2 reported bugs cropped up
o To fix one, needed to update to 2.0 (deferred object
cleanup)... this caused rather a lot of upset, as the
sysadmins were upset about such a huge package needing to be
updated (and they tried to do just the core packages first,
which doubled the work-load involved in preparing that
update versus using Sumo)
o Fixing the other was no big deal, except that something in
2.0 changed how the test-suite was running so that it now
hung on completion...
* Now, at this point there had been serious conversations just an
hour earlier during a management meeting about replacing Twisted
for 2 separate projects. The entire company is watching as we go
to fix the *trivial* error while we're together after the
meeting... but the test suite won't complete. Must be something
wrong with the background thread not exiting thinks I.
o What do we call to shutdown the threadpool? I don't
remember, let's check the reference docs... 20 minutes of
searching for the 2.0 reference docs (with the entire
company watching this)... finally ask on IRC... told to
build them myself and contribute them. Cute, but didn't
really drive home the whole "robust, professional,
well-documented platform on which to develop business
systems" meme as much as I'd hoped. (Some of that is
definitely my fault, I was pretty frustrated by the time I
went to IRC to ask where the documentation was).
o Finally go with the 1.3 docs, hoping there's not some change
to the API that's causing the problem (though that looks
very probable at this point, the change to 2.0 being the
primary difference between working and not).
* Finally get the 1.3 docs, hack together a
reactor.threadpool.stop() call with a dummy last-run-test-suite
and get the test suite to run-and-exit...
o Keep in mind, we've just had to introduce a glaringly ugly
and fragile hack to get around something trivial. There may
be a better way to run the tests, but it's a bit late for
thinking of that now...
* Now that we can run the test suite and focus on what happens
during it, we discover that the ESMTP client can't connect to a
local SMTP host without authentication (or at least, it wouldn't
with the code we were using across the network to a remote
host)... no documentation on the ESMTP client, of course.
* At which point my colleague (lead on this project) got well and
truly fed up and decided to dump Twisted and rewrite the project
There's lots of points where, had I anticipated the problems, I might
have salvaged the project in its current state. If I'd anticipated that
the problems would be non-trivial to fix, I could simply have returned
to my workstation and fixed them in a relaxed and pressure-free
environment. I could have spelunked through the code to figure out the
interfaces in lieu of documentation. That's fine for me, I already
understand Twisted enough to spelunk through and find what I want, but
it doesn't make a great argument when someone's simply mystified by all
the pieces scattered here and there that seem to be joined by nothing
more than hope and bailing wire.
I could have done better at evangelising. In the end, though, I had to
concede that stripping out Twisted and writing the code himself would
probably be faster and easier in the long run than trying to work around
problems in an under-documented "foreign" system (again, from his
Especially given the small size of the project, a few simple select
loops and a thread can solve 90% of what Twisted is providing for him.
Thinking back on that conversation; at that point the *only* failing
feature was the ESMTP-sending, and I'm pretty sure it would have
resolved to something like passing a None instead of a "" for the
username and password; but when it came right down to it, he's the one
maintaining the code, and as far as he can see, Twisted just gets in the
Don't know if the other project will be rewritten as well. Given
decision on this one, I'd imagine it will. I'd also predict that
Twisted is now Techne non Grata wrt any new development where it's not
an explicit requirement (given that we're going to be eating costs on
rewriting a project to eliminate it). Certainly I'll have a hard sell
So, anyway, just felt the need to share that. Sorry again for the sharp
post to IRC.
 How did ESMTP get in there anyway, if it's a 1.3 codebase? Well, it
shares common functionality with the big application, one piece of that
being the automated use of ESMTP.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Twisted-Python