andrea at cpushare.com
Sat Jan 21 20:53:12 EST 2006
if you've pending patches that have not been applied or you've
no time for unittests until your project works, you can consider
switching to CPUShare-Twisted. Mercurial allows distributed development
so we can merge our branches against each other with very little effort.
If you've suggestion for betters names you're welcome. I could have done
it over sourceforge but they lack mercurial AFIK and since I've the
setup on cpushare.com I was quick to add Twisted to it. We can move it
elsewhere later if needed (especially if it consumes too much network
I have no interest to maintain twisted except for the fact I'm using it
in semi-production and I plan to use it in production, and so I need it
to be stable, and with all possible bugfixes and features applied
without formalities. I assume other business usages of twisted may have
the same needs, so perhaps we can join our efforts with this project.
My choice was to either dump twisted or to maintain it locally, and so I
clearly have an interest to make the CPUShare-Twisted branch public and
to include other people fixes and features (I was already maintaining it
over the last year except it was just a patch with fixes that I failed
to push in SVN, and not a real fork).
You can find the quickstart, basic objectives (including the not trying
to reinvent the wheel) and mailing list details on the project page:
I'll keep tracking SVN. I'll also keep submitting patches upstream since
one can always hope for the best.
Also note, over the last year I've fixed at least one bug in core
twisted basic protocols that would have never been found with any
unittest out there. Careful auditing and reading code and filtering of
the patches, and thinking deeply about the design before writing code
(to write the code in a way that won't break easily over time), is much
more important than spending time on unittests. Unittests still makes
perfect sense after stuff is included and works in basic testing, but
they should be separated from the logic of committing valid patches to
NOTE: before clicking on that page you may want to also answer these
1) is python much better than ruby and all other language on earth?
2) is twisted much better than any other framework to write network apps?
3) are twisted and python fast and scalable enough for all applications?
4) is the single threaded model scalable enough for all applications in
5) is async programming using deferreds simpler to code for a webserver
that is stateless and that only does sql queries over the network?
6) would you rather prefer to go broke than to use code
"not-invented-here" or not written with python and twisted?
(of course the python interpreter the c compiler and the underlying
operative system are magically excluded from the not-invented-here
clause for whatever unknown reason)
I'm welcome anybody who wants to join cpushare-twisted, but if the
answer of _any_ of the above questions is "yes", I think you may be
better off ignoring this email.
More information about the Twisted-Python