Python Framework Comparison: Django vs. Pyramid

This short comparison of the Python frameworks Django vs. Pyramid was written by Codementor Sheena, who has been working with Python for 6 years and is currently involved in creating tools that make hadoop more useful.

Introduction

Having worked extensively in both Django and Pyramid, I tend to favour Pyramid. But it isn't the most suitable all the time. Here's a little round-up of the differences between the two popular frameworks to help you decide which is suitable for your work.

Getting Started

If you want to go from zero to hero as quickly as possible then Django is the framework for you. The learning curve is not quite as steep as Pyramid, also the Django Book (Django's official mega tutorial) is a wonderful thing. The first time I heard of Django was the first time I heard of Python. My experiences as a noob dealing with Django were for the most part pretty good - it is very noob friendly. Getting started with Pyramid is a little more difficult but with good reason.

Flexibility

Pyramid wins this one by miles.

In order to produce a useful web application you will need a frameworks that can tie together a number of components (this is not an exhaustive list): A template rendering system, a way to connect to a database, a way to map urls to views, some kind of authentication system, and a bunch of other things. Pyramid is great in that all of these components can be swapped out. You have your pick of template rendering engines; you have two different ways to map urls to views and you can use them both in the same app; you can use whatever method you want to connect to a database (although SQLAlchemy is generally used), and can even connect to multiple databases of very different types.

With Pyramid you can start off with something really bare bones and build up in whatever way you need to. Here is a really simple Pyramid app. It runs, it serves, it's pretty useless but it is self contained.

from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.response import Response

def hello_world(request):
    return Response('Hi there')

def main():
    config = Configurator()
    config.add_route('hello', '/')                        # url dispatch
    config.add_view(hello_world, route_name='hello')
    app = config.make_wsgi_app()
    return app

if __name__ == '__main__':
    app = main()
    server = make_server('0.0.0.0', 6547, app)
    print ('Starting up server on http://localhost:6547')
    server.serve_forever()

Django, on the other hand, has its own template rendering system, it's own ORM (object relational manager - used to talking to databases), its own mostly everything. This does make the learning curve a little more friendly for new developers since there are way fewer choices to be made, but it definitely has its cons.

Admin Interface

One of the killer features of Django is its admin interface. It makes it really easy to generate an administration site straight from an application's models. If that made no sense I'll draw you a picture:

Say you have a web app that you use to keep track of all the crayons in your life. Yes, crayons. Each crayon has a bunch of attributes like colour, brand, length, girth, pointiness. Each crayon lives inside a pencil-case. Each pencil case has a colour and dimensions. Each pencil case is in a room in your crooked little house, each room has a name and a boolean value to indicate whether or not we can draw on its walls. So that gives us 3 different database tables and a few foreign key relationships between them. If that last statement didn't make sense then you might want to read up a little on SQL at some point. If you are interested in this tutorial SQL will probably be useful to you anyway.

So we've come up with what tables we want and we write up some models (classes representing the tables so we can interact with database rows in a friendly way. Lookup ORM if you need some detail here). The next step is to make a bunch of views - we'll need to manage rooms (add, edit); manage pencil-cases (add, remove, edit); manage crayons (add, remove, edit); and manage the relationships between those items. There seems to be a lot of repetition in this. Here is the crux: If you were writing this in Django, you wouldn't need to write all that code! Django is clever enough to put it together for you. This can be a huge time saver.

Django doesn't do everything for you - you need to tell it which of your models should be accessible via the administration interface. You also have some control over how your models are turned into forms and suchlike by specifying things like field types and default values. Here is some code for creating a model and adding it to the administration interface:

class Room(models.Model):
    name = models.CharField(max_length=30)
    can_draw_on_walls = models.BooleanField()
    
admin.site.register(Room)    

Note that this is code is very minimal, the admin interface can do a lot of things and be customised in all sorts of ways. That said, tweaking the admin interface can take a lot of time so if you want something very fancy then Django and Pyramid are actually tied on this point.

Ease of AJAX

Pyramid wins this one. Use of decorators and XHR views make it very easy to get AJAX requests to go where you want them. Explaining XHR, decorators, or AJAX is way outside the scope of this tutorial but I assure you the explanations are out there.

In Pyramid, to add an xhr route you could do something like this:

config.add_route('test', '/test', my_view, renderer="json", xhr=True)

Or this:

@view_config(... xhr=True)

If that doesn't make sense don't worry. If you choose to go with Pyramid then this will look pretty straight forward once you get into things.

Django does not have a comparable xhr mechanism.

Code Layout

Django makes use of things called applications in order to make it easy to plug new capabilities into your product. This is very good in a way because it encourages developers to write code that is self-contained. It also makes incorporating applications from other sources pretty straight-forward, and reading other people's code easier. Django has a bootstrapping mechanism for creating new applications within a project.

python manage.py startapp books

This command creates a new application called books within the current project. Once an application is created it needs to be installed, that is, the project must be updated so that it 'knows' about the new application. This is done by updating the project settings file. If this makes no sense to you, I will again refer you to the Django book.

Pyramid on the other hand lets you do whatever you want but has a few conventions in place. So that is a pro and a con. Pyramid's code layout conventions are largely encouraged through use of scaffolds, a sort of bootstrapping mechanism. When starting a new Pyramid project you can either make all your files from scratch (which is hardly ever worth the time) or create a base project to work from through use of a scaffold. There are a number of different scaffolds that come standard: the alchemy scaffold is optimised for SQLAlchemy; and the zodb scaffold for ZODB. There are also various scaffolds available for download. To create a new project using a scaffold we use pcreate from the command line. Like so:

pcreate -s alchemy hello_alchemy

This creates a project that has all the bits and pieces in place for creating an SQLAlchemy based Pyramid application, and names the application hello_alchemy.

In summary, Django is pretty strict here, and Pyramid is not. Django forces you to stick to certain conventions that can be confusing for new programmers; and Pyramid give you the option of which conventions you would like to stick to (which can also be confusing for new programmers). Pyramid's approach here is another expression of the flexibility it provides.

SQLAlchemy Support

SQLAlchemy is a very powerful thing, a lot of very clever people think it's the best ORM around. If you choose Django you choose not to use SQLAlchemy. It is only a big deal if your application is very (SQL) database intensive - if you want to do complicated queries in a sane way. On the other hand, if your app is simple then SQLAlchemy wont be a big help, but it doesn't hurt to have it.

Community and Support

This one is a tie. The communities that use and support both Pyramid and Django are huge.

Conclusion

Personally, I prefer Pyramid - the flexibility it allows is very appealing and makes it quite fun to work with. But there are definitely reasons to use Django instead. The two frameworks both deserve and have huge followings. It is pretty hard to say which one is better. They were designed with similar end goals and fill the same niche, but their different philosophies are apparent in almost every aspect of their respective designs. Pyramid is great because it is flexible and Django is great because of its batteries included philosophy.