[Twisted-web] CPUShare-Twisted

Lawrence Oluyede l.oluyede at gmail.com
Sun Jan 22 03:33:56 MST 2006

> 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
> the tree.

I think nobody here is claiming that you're not a useful to the
Twisted effort. Mr. Lefkowitz has already apologized for the delays of
applying patches (mostly due to lack of unit tests and manpower) but
stating that a great eye on code is better than automatic testing I
think it's wron and I don't know where one excludes the other. You can
can write test, use your experience to read through it and find if
it's correct and submit to the Twisted folks. It's very normal to
apply a pending patch on your local Twisted tree while waiting that
they apply it on the trunk. Delays? Why you don't join the project?

> NOTE: before clicking on that page you may want to also answer these
> questions:

Let me say that reading those kind of question I'm starting to think
that Twisted it's not what you need in first place, so why bother
rewriting your app N times or wasting your time here if Twisted is not
what you need? I specifically refer to the question #5

> 1) is python much better than ruby and all other language on earth?

Than Ruby? The answer is no. It's a matter of tastes. Than all the
languages? Who knows them all?

> 2) is twisted much better than any other framework to write network apps?

Which other framework do you know? I'm aware of ACE for C++ and
another for Perl. Full stop. There are languages like E, like Oz
having concurrency support builtin but they aren't "frameworks"

> 3) are twisted and python fast and scalable enough for all applications?

Twisted and Python are scalable enough for all applications that uses
them. If you need something powerful why using them? I don't
understand your kind of questions.

> 4) is the single threaded model scalable enough for all applications in
>    smp?

The same as above.

> 5) is async programming using deferreds simpler to code for a webserver
>    that is stateless and that only does sql queries over the network?

That's my main concern. If you have stateless stuff and you do only
sql queries, do you really need all the twisted power?

> 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)

What's the meaning of such a question?

> 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.

I wish you luck but this clause terrifies me:
"If the CPUShare-Twisted fork fails to be successful, CPUShare will
stop using Twisted, so the use of this fork is at your own risk."

If you have find time to write countless emails on this mailing list,
to say that Nevow is ugly and slow, to whatever... why didn't write
unit tests for patches and stop?

I don't understand the real point to your argues.


More information about the Twisted-web mailing list