Python's definitely got a web framework problem. There are too many frameworks, and they all suck! It looks like it's getting better because people are writing tiny wrappers around CherryPy and making things like TurboGears and Subway and Django, but the suckage is still there! The fundamental problem is that when everybody is working on disparate projects, you don't get a framework that everybody can use! You get a framework that's good for the author, and that's it. In fact, I don't even know if the authors of a lot of these projects actually use them to develop a big application!

You need a large community if you want to design a framework that's got the right design for everybody -- it's an evolutionary process, and evolution doesn't work unless you have a big population!

I liked this post to the webware-discuss mailing list by Olivier Favre-Simon:

I've been using python for some time now, mainly for PyGTK desktop GUI's or XMLRPC/SOAP web services, but for pure web development I'm coming from a PHP/Smarty background.

PHP is good for rapid prototyping but on the long-term it's all spaghetti code with screens "pulling" the data from databases. Rails is really cool but it's Ruby ;-)

It's a pity for me to see that python (IMHO the best language whatever the domain you're working in) has 10 or so web frameworks with as many template engines. That's too many brainpower dissipated in duplicate endeavours. PHP and Rails are strong because the whole community agreed that choosing a "main" (in not single) framework was more important than any technical argument/point of view/limitation/whatever.

If we want python to *really* make it on web servers (I mean as an opensource initiative, not Zope), the only way to succeed is (by priority order):

1. Stop/refrain from developping new features when the existing codebase is so poorly documented. (Microsoft MFC and .NET are crap but the documentation is really impressing and make it possible to start from scratch in very little time)

2. Add many examples and a real tutorial. What I mean is that one must not have to copy/paste from html pages to have a running tutorial site. We should have say a webware-examples.tar.bz2: just unpack it in some /opt or /var/www directory, tweak httpd.conf a little and it must be running from scratch).

3. Clearly an non-ambiguously define which packages are prefered and which are deprecated: e.g. Many people advocate SQLObject for Rails-alike sites (which I agree), but nowhere is it clearly defined that one must choose SQLObject over MiddleKit, say for new sites. e.g. I completely failed to understand what UserKit is meant for and how to use it; googling about it did not return valuable info or a good example.

4. Release early release often: The only thing that stops me to actually put big Webware sites on the corporate servers in the company i'm working for is seeing that same 0.8.1 version for so long. I know that development is still going on: I'm regularly updating my development box from [EMAIL PROTECTED] webware module but any serious management will throw me away if I ever speak of a CVS version on a prod server (even a tiny one).

Trust matters, and the best way to ensure trust is to *show* that things evolve; knowing it is not sufficient.

What we need is JOINING FORCES (and not only in Webware+Cheetah; other web frameworks (heho Aquarium) have common needs/requirements: form handling, session management, etc.

Another problem I see is that all the Python web framework people want to reuse existing modules (like ORM and template languages) and glue them together awkwardly, instead of rewriting everything so that it fits smoothly together. I mean, the Rails-like frameworks aren't even based off their own codebase -- they're just bolted on top of CherryPy!