I wanted to emphasise that it is not just TurboGears that is going great guns at the moment in the Python web world.
There is another metaframework Subway that is also moving fast. To be honest I believe the differences are becoming relatively small between them. Subway is tied to Cheetah as a template language (mature and nicely orthogonal to html/xml) whereas TurboGears uses Kid (focus on well formed xml and html). The other differences (support for CherryFlow in Subway) could be easily added to the other.
I am not about to argue that these two projects should merge, instead I feel they can improve most by making sure that they each stay thin putting all the improvements they can back into the components eg CherryPy (which they both have been doing) and into the deployment elements (setuptools and paste).
The other framework (not a metaframework but an all encompasing framework making it the most direct challenger to Rails) is Django. Although it does not re-use much of other projects there are still common elements coming through such as Python eggs (hopefully Paste too in the future). So again this is helping grow the overall solution.
I suspect that an integrated solution like Django will appeal to organisations seeking to standardise their development where as other solutions may be easier to integrate with existing elements (and fit better with my own philosophy see 42: MarkShuttleworth - Ubuntu Wiki and 42: Is TurboGears to Python what Ubuntu is to Linux?).
Another project that is the next level down from these frameworks but that is also moving fast is Quixote, I feel the differences between Quixote and CherryPy are also becoming smaller (shown by the recent blog posts on Python Web Controllers). Whether they could ever merge is a different matter. Probably not possible (or even desireable) for the moment.
Also Myghty should be mentioned as another stable framework that fits in with PythonPaste (although my preference is to not embed code inside templates).
Hopefully though the work on Python Eggs and Paste will at least mean that applications written in these different (meta)frameworks can run alongside each other, while the tools that many share (eg SQLObject) also benefit from lots of use and users.

Myghty doesn't have any requirements that you put your code in the templates, anymore than Cheetah does. You can put as much or as little code in the templates as you like, the flexibility is there because sometimes it just has to be done.
I'm a fan of using the MVC approach, so I throw all my logic into the Controller then try and minimize the login in the templates. The controller I showed in my Controller round-up was using Myghty's Implicit Module Component style, though I prefer using my Routes project or the explicit dispatch style.
Posted by: Ben Bangert | Friday, October 07, 2005 at 03:51 AM
I find it interesting how Zope still seems to be ignored completely in overviews like this. Zope is moving fast too. Zope 3.1 was released this week, Five 1.1 (Zope 3 for Zope 2) was released this week, we've had a Zope 3 quickstart published a few days ago as well. Meanwhile Zope 3.2 is in progress and has integrated Twisted and does WSGI.
With all the work that's been done, and the steps taken to make Zope 3 a good Python citizen, some token *mention* of Zope in this kind of Python web framework overview would be appreciated. :) Obviously Zope needs to learn a lot in the hype and appeal to newbies department.
So, no, it's not just TurboGears.
Posted by: Martijn Faassen | Friday, October 07, 2005 at 09:44 AM
Martin,
Yep unfair of me to miss zope. My only experience has been through plone. Zope always seems to me to be a bigger solution, from a hosting POV it is not going to be suitable for the types of sites I am interested in (Churches etc).
Still from my own POV I am not interested in all encompassing monolithic solutions and that is the way I perceive Zope (and to a lesser extent Django). I perceive them as too heavyweight and inflexible.
In any post that supposedly covers the range I should have covered Zope and Twisted and no doubt others too.
Posted by: DaveW | Friday, October 07, 2005 at 11:07 AM
Zope 2 has rightly the reputation of being big and monolithic. Zope 3 aims to be much less so. It mostly succeeds, and continues to be improved in this respect.
Anyway, Zope 3 is thus moving also towards the Pythonic center where it's not monolithic and "all or nothing" and integrating well with other Pythonic things like WSGI and eggs. It's an interesting time to live in concerning python web application systems. Zope 3 is explicitly part of this time.
Posted by: Martijn Faassen | Friday, October 07, 2005 at 03:00 PM
Hey DaveW: Regarding your comment of Django being "monolithic"... Although it comes with sensible defaults, for ease of use and smart integration, Django was designed with loose coupling as a paramount goal -- so, for instance, you can use whatever template engine you want.
I realize how it may seem to be monolithic, because it does a hell of a lot, and does it well, and comes with a lot of sensible defaults. But, that's the whole point! The point of a Web framework is to offer a full-stack way of doing Web development.
Django is no more "monolithic" than TurboGears. Both are full-stack Web frameworks. But Django does more -- for instance, it gives you the option of creating an admin interface for your content automatically. (Which is one of the main reasons people have been going crazy for it.)
"Offering more functionality" != "Being monolithic".
I like your reference to Ubuntu -- that it's really good at cobbling together unrelated parts to create a cohesive whole. I use Ubuntu myself on my desktop machine, and I love it. But the scope of a Web framework is *much* smaller than the scope of an operating system -- and while I think cobbling together unrelated parts is a smart thing (and the only realistically *scalable* thing) to do at the level of the Linux operating system, it's not as advantageous to cobble together unrelated parts to create a Web framework. Whenever things *can* be integrated, integrate them.
The fact that every level in the Django stack was custom designed to work well with the other levels of the stack -- and used in production for the past 2 years -- is an *advantage*.
Posted by: Adrian Holovaty | Friday, October 07, 2005 at 03:18 PM