Zope 2 was a Python-based web development framework that built all its components in-house and has been superseded by Zope 3 and taken in a different direction. TurboGears is a newer Python-based web development framework that seeks out best-in-breed projects rather than roll their own. Mark Ramm is a core developer on the TurboGears project and is bothered by the fact that the Django community seems to be heading down the Zope 2 path under the auspices of the "batteries included" philosophy.

In the Python community, many see the Django community as separate from the other web development projects due to these difference in philosophies, Ramm said. He went on to further claim that Django is in some ways harming or at least doing a disservice to the the Python community as whole because much of its internal components cannot be easily used outside of the rest of the Django project. By the same token, Ramm believes that Django core developers could be spending valuable time and resources improving and integrating many existing projects, Beaker and SQLAlchemy for example, instead of reinventing their functionality. Furthermore, many of these established 3rd-party projects have long ago addressed and solved many perceived pitfalls of Django.



Mark Ramm takes exception to this oft-repeated Django-catchphrase Mark Ramm takes exception to this oft-repeated Django-catchphrase

Ramm's central premise is in fact a balancing act that the framework seeks to maintain. The project attempts to package as much of the functionality (barring database drivers and the like) into a simple to install package that's friendly to newcomers. Constrated to TurboGears, for example, which could require a handful (or two) of dependencies to install. Which audience does Django want to maintain: one of individuals who want a tool to get things done, or an audience of bright programmers who are willing to trod through several hours of package maintenance for a slightly more robust solution? Django seems to be pushing for the former, and so far their decision has benefited them.

Another of Ramm's fears is that programmers pulled into the Django world will in effect become Django developers first and Python developers or web developers second. To a certain extent this is true, but Django developer James Bennett during the Q&A portion rebutted that rarely do developers come to the decision on a framework with SQLAlchemy, a stack of WSGI middleware, and Beaker in hand; they just want to launch a product with the least amount of friction as possible.

The pronouncements of doom and gloom do have a basis in some people's realities. It's true that Django could be putting in work to gain advanced database features offered by SQLAlchemy, but the gains really only apply to a small subset of their potential audience. Django core developers are much more supportive of making Django pluggable enough that 3rd-party developers incorporate these packages themselves. Recent changes deep inside the project (i.e. queryset-refactor) now allow developers to write or adapt just about any datastore backend (Jacob Kaplan-Moss mentions candidly that he has Django running on to of Aperture's Core Data store and a non-relational database with CouchDB).

The general feel of the day was that Django can do some things to improve their position in the Python ecosphere. Removing barriers in the core of Django to enable a wider range of extensibility looks to be a definite eventuality; and on even a few occasions, core developers mentioned they'd be looking more seriously into relying on 3rd-party libraries and packages for new functionality.