The very most right-leaning web framework is PHP: it's so right-leaning it's not really a framework. Pylons is very much a "right-leaning" frameworks (someone at PyCon referred to it as a "drawing of a hammer" in contrast with the famed hammer factory factory featured in a Joel on Software blog comment ). Zope is very much a "left-leaning" framework (it is certainly the most left-leaning Python framework; I suspect Smalltalk frameworks would be left-leaning but I've never used one so I don't know). Django and TurboGears fall somewhere in between, though maybe they're more right-leaning than left leaning. I suspect Apple's various frameworks are pretty left-leaning, but I'm not really an Apple developer either. UNIX is a right-leaning framework; Windows leans more left.

"Right leaning" frameworks place more responsibility on developers, end users and integrators. Therefore, they are usually materially simpler than left-leaning frameworks, which tend to assume a lot of the responsibility that isn't provided by the right-leaning variety. On the other hand, left leaning frameworks, because they provide a lot of functionality are typically harder to understand and develop for initially, because you need to understand a lot more before you begin to write code but they tend to provide features that can prove useful later in development and deployment that are ignored by right-leaning ones.

This distinction has consequences on applications developed within them. In applications developed in "right-leaning" frameworks:

• One instance created by an integrator or end user is assumed to serve up (mostly) a single instance of a single application (e.g. "the blog", "the tagging system"). If another application is required, or another instance of the same application is required for a separate audience, it's more likely that right-leaning framework integrators will create a separate build of the entire framework stack to run the new application or instance rather than attempt to integrate into an existing build than might be the case under a left-leaning framework. Developers of applications under right-leaning frameworks are not culturally encouraged to make it possible to run two (slightly different) instances of the same application within a single process space.
• The number of configuration knobs exposed by the application to end users and/or integrators is typically fewer in right-leaning frameworks than code developed under left-leaning frameworks; instead it's assumed that an integrator or end user will change code directly to get the behavior he needs. For example, environment-specific settings tend to be stored in Python code within files belonging to "the application" along with the application code itself with only a conventional distinction between the two.
• Because applications are more tightly focused, it makes builds less complicated than under a left-leaning framework. Therefore, the developers of applications under a right-leaning framework don't place much stock in making instance builds repeatable in an automatic way. This task is more often left to the end user.
• It's usually easier for right-leaning framework authors to document their framework, as there's less of it.

In applications developed in "left-leaning" frameworks:

• Application developers are expected to implement a great deal of functionality required to satisfy various aspects expected by the framework or the culture surrounding the framework.
  • Environment-specific settings are stored in configuration files or other instance-specific data structures that are separated very distinctly from the software that uses these settings. It's almost never the case that configuration knobs are put into Python files that ship along with an application; it would be a dramatic cultural faux pas.
  • Left-leaning frameworks tend to attempt to provide more facilities that allow developers to inject pluggability and allow behavior to be overridden without an integrator or end user needing to fork their code. Developers are expected to provide these plug points to integrators and end users.
  • One build of the framework is assumed to serve up more than one application (a blog application and a tagging application). It's not uncommon for a single framework build to contain many instances of a single application ("a blog for fred, a blog for sally", "a blog for brad", "a tagging system for customer a", "a tagging system for customer b", etc). Cultural requirements dictate that developers make this possible, which adds to their work load.
• Because left-leaning frameworks tend to provide a lot of functionality, and because the first attempt at the functionality is almost always wrong, they tend to accrete multiple implementations of very similar things over time. The old implementations aren't removed because applications developed previously rely on them. This can provide a dizzying intiation for new developers (do I use "way A" or "way B?")
• Because there's so much framework, left-leaning frameworks tend to be more sparsely documented in total, just because documentation tends to lag behind code.

It's often far, far easier for people to start writing code using a right-leaning framework than a left-leaning one simply because there's a lot less to learn. A poorly-documented right-leaning framework is easier to develop in than even the best-documented left-leaning framework. If you're just starting out and you need to develop an in-house application that won't be redistributed or reused, a right-leaning framework is almost certainly a better choice: many of the features of left-leaning frameworks are there to support redistribution and reuse.

On the other hand, if the goals of a left-leaning framework line up with your problem domain, despite a steep learning curve at the beginning, it might be wise to use one rather than a right-leaning framework. For example, Zope is exceedingly good at providing arbitrary-depth document hierarchies out of the box, whereas this behavior tends to need to be created from scratch for each job in right-leaning frameworks. It's typically far easier to retrofit a Zope application to go "one level deeper" than it is to retrofit an application written in a right-leaning framework.

All that said, personally, I'd like to see Zope lean a little more right. Because it has so much history, it's pretty difficult to make it do so. Our shot at it has been in the form of Repoze which attempts to make Zope do less by pulling functionality out of Zope and into smaller distinct pieces. These pieces should be more easily understood and used by people who don't want to bite off an entire left-leaning framework. They can even be used by people who might otherwise be using right-leaning frameworks. Grok leans more right than does Zope, which is gret, but it's still more left-leaning than any of the other existing Python web frameworks because it has historically had a focus on general "approachability". This drives its inventors to want to solve very general problems by writing more framework software rather than by placing particular bits of responsibility on end users.

I imagine a lot of the current right-leaning frameworks will evolve more left-leaning tendencies as they become more ambitious. Both Django and TurboGears seem to be shaping up this way. This path needs to be treaded carefully, but I think both of these communities have excellent leadership, which should take some of the risk out of "going left". In the meantime we'll go at it from the other side, trying to pull bits out of Zope that should form a slightly more right-leaning set of components. The future looks very bright. Viva la 4th generation of Python web frameworks!