Rationale

As of early 2011, there is a lot of flux in the Python world with regard to web frameworks. There are a couple of big players, namely Django, Pylons, and TurboGears, as well as several more obscure projects like CherryPy and Bottle. Having worked with many of these projects, I decided that although each has its strengths, they all also had something about them that just made me feel uncomfortable working with them.

Framework Comparison

Django

Strengths

  • Very popular and actively developed, making it easy to get help and solve problems
  • Fully-featured, including an Object-Relational Mapper, URL dispatcher, template engine, and form library. Also includes “goodies” like authentication, an “admin” application, and sessions

Discomforts

I am not specifically listing any of these issues as weaknesses or drawbacks, because they aren’t per-se. Honestly, there isn’t anything wrong with Django, and many people love it. Personally, I don’t feel comfortable working with it for a few reasons.

  • Storing configuration in a Python module is absurd
  • All of the components are so tightly-integrated it is nearly impossible to use some pieces without the others.
    • I really don’t like its ORM. SQLAlchemy is tremendously more powerful, and isn’t nearly as restrictive (naming conventions, etc.)
    • The session handling middleware is very limited in comparison to other projects like Beaker
    • I am not fond of the template engine and would prefer to use Genshi.

Pylons/Pyramid

The original Pylons was a very powerful web framework. It was probably my favorite framework, and I have built a number of applications using it. Unfortunately, development has been discontinued and efforts are now being concentrated on Pyramid instead.

Pylons

Strengths

  • While not as popular as Django, there still a significant following
  • The code base is very decoupled, allowing developers to swap out components without affecting the overall functionality of the framework.

Weaknesses

  • Overutilization of StackedObject proxies and global variables

Pyramid

I simply do not like Pyramid at all, and it is really disappointing that the Pylons project has moved in this direction. Essentially everything that I liked about Pylons is gone. The idea of using traversal to map URLs to routines is clever, but it is overly complex compared to the familiar URL dispatching in other frameworks.

  • Tightly integrated with several Zope components, mostly interfaces (puke)
  • Template renderers are insanely complex and again, I don’t like Zope interfaces. There is no simple way to use Genshi, which I absolutely adore.

Other Frameworks

I haven’t used the other frameworks as much. In general, I try to avoid having my applications depend on obscure or unmaintained libraries because when I find a bug (and I will), I need some assurance that it will be fixed soon. I do not like having to patch other people’s code in production environments, especially if it is an application I am passing along to a client.

I never really looked at TurboGears at all, and with the recent changes to the Pylons project, upon which TurboGears is based, there is a great deal of uncertainty with regard to its future.

CherryPy is very nice, and I did a bit of work with it a while back. I thought it was dead for a long time, though, and I have never really produced a production application built on it. With its most recent release (3.2.0), it is the first web framework to support Python 3, which is exciting. I may revisit it in the near future, as a matter of fact.

The Truth

The truth is, I started Milla as an exercise to better understand WSGI. All of the frameworks discussed above are great, and will most likely serve everyone’s needs. There really isn’t any reason for anyone to use Milla over any of them, but I won’t stop you.

Project Versions

Table Of Contents

Previous topic

Welcome to Milla’s documentation!

Next topic

API Reference

This Page