[Twisted-python] Writing industrial grade twisted servers
exarkun at divmod.com
Tue Jun 17 11:46:37 EDT 2008
On Tue, 17 Jun 2008 11:36:40 -0400, Black <python at blackslens.com> wrote:
>On Jun 17, 2008, at 10:08 AM, Itamar Shtull-Trauring wrote:
>>On Tue, 2008-06-17 at 08:49 -0400, kevin beckford wrote:
>>>Where do i read to find out how to simply create a production quality
>>There are some better *deployment* techniques documented here -
>>but they just make things easier to deploy, they don't make your
>>software "production quality."
>>Production quality software is hard; a good start is having code
>>reviews, well-written unit tests that cover all your code, as well as
>>end-to-end regression tests. The deployment techniques above do tend to
>>lead to slightly more testable software (by encouraging you to write
>>your software as Services).
>Unless I misunderstood the first mail, I don't think this is what Kevin
>meant . I believe what he is looking for could better be termed "best
>practice" (it is probably the reference to "industrial grade" in the
>subject that is misleading). This is something I've struggled with as well
>with respect to Twisted. Twisted is large and complex and in many cases
>there are several ways to achieve the same functionality. Frequently, it
>isn't easy to figure out the "best" approach or even the generally accepted
>approach. As Kevin says, the documentation does make obscure references to
>there being some "way you usually do this", without coming out and saying
>what that way is. All of the code reviews and unit tests in the world
>aren't going to catch unconventional uses of a library unless one of the
>reviewers knows better...
>I'd offer some advice of my own, but I'm not sure even now that I use
>Twisted properly - at best I have something that works, and as all of my
>work is experimental that has been good enough.
A way to get better answers to this question is to file tickets for each
place in the documentation which makes this unsubstantiated claim. Then
the documentation can be improved, either by replacing the code in the
documentation which doesn't conform to best practices with code which does
conform to best practices, or by removing the claim if it's just so much
This helps everyone who reads the documentation in the future, and it makes
for a *much* easier question to answer than "What are the best practices for
developing Twisted applications?" (which I don't even know where to begin to
answer, unless you've got about a week).
More information about the Twisted-Python