Today I went through the Single file tutorial in the Pyramid documentation. This tutorial was starting to sway me away from the framework, due to all I needed to do, just to create something as simple as a Tasks list application. I was seeing little benefit in using it over say Django. Rather than finishing the tutorial, I did skim through the rest of it, to see what it was all about though. I went on to the Wiki tutorial which uses SQLAlchemy. The initial project configuration was similar to other major frameworks, running a command-line program to start the project and select a few additional options. I was beginning to become more interested. The resulting project directory also contained some default templates, css, and images to work with. This is something which Django does lack in, and it expects you to create all your templates from scratch.

Unlike Django, in Pyramid, there isn't a single manage.py, but rather a large array of scripts in your binary folder. This makes it a little confusing at first, as I am used to using either django-admin or manage.py for project configuration.

A component I really like about Pyramid, is that it automatically comes with a nice debug_toolbar, it looks the exact same as django-debug-toolbar. The default template which comes with a Pyramid project looks modern, despite the copyright date on the bottom still displaying 2011, maybe I'm just a tad picky. The debug toolbar here comes with some extra sections I do not see in the Django version, namely Routes, Tweens, and Introspection. I especially like the inclusion of Introspection, as I am sure it will prove most useful with debugging of an application. I am most confused about Tween, as this is from Flash development, it does make me curious of it's exact purpose.

It feels like Pyramid is trying to be the next Django in some senses, where much of the work is taken care of, and there is separation in the project layout. For web development, I am still preferring the Django ORM over SQLAlchemy. Looking at a simple models.py in either framework shows which APIs are more straightforward:

from sqlalchemy import (
    Column,
    Integer,
    Text,
    )

from sqlalchemy.ext.declarative import declarative_base

from sqlalchemy.orm import (
    scoped_session,
    sessionmaker,
    )

from zope.sqlalchemy import ZopeTransactionExtension

DBSession = scoped_session(sessionmaker(extension=ZopeTransactionExtension()))
Base = declarative_base()

class Page(Base):
    """ The SQLAlchemy declarative model class for a Page object. """
    __tablename__ = 'pages'
    id = Column(Integer, primary_key=True)
    name = Column(Text, unique=True)
    data = Column(Text)

    def __init__(self, name, data):
        self.name = name
        self.data = data

This is a very simple data model which basically describes a key/value store. This is SQLAlchemy/Pyramid's data model usage syntax. It appears to be overly complex for just describing a simple model. Here is the same model, but using Django's ORM:

from django.db import models

class Page(models.Model):
    name = models.TextField(unique=True)
    value = models.TextField()

In Django, that's all there is to it. It's easy to read and straightforward to develop. Although, I think the name field should really be a VARCHAR, not sure why the Pyramid tutorial uses a TEXT field. Django also provides customizable Fields, such as a SlugField, which works wonders during developing a web application. Anyways, enough bashing of the other framework/ORM, lets get back on topic with Pyramid.

I like that Pyramid has a setup.py module which can configure a dependency list, this makes deploying the application to a server or moving the application to a new server relatively simple. It reminds me of how Rails is setup.

Okay, so I went through the tutorial. Although Pyramid does not provide rapid development. It does seem to have it own perks. Since it is based on Paste, it simplifies deployment. The entire framework is right in your face, which means all components are very customizable without having to fight with the framework. I may use it one day, if I find a project which requires a good amount of customization which Django cannot provide. As I said in a previous blog post, it is really hard to leave the wonderful world of Django. I try to look at other frameworks, but Django seems to offer the best in rapid development, customizablity when I require it, and works behind the scenes when I don't.

As a web developer, I like to focus on my application and now how the underlying framework works. I want a nicely integrated API which is highly documented and very easy to understand and use. Over the course of all the frameworks I have tried in many different languages, Django seems to provide all of this, in one easy to download and install package. Other frameworks have so many dependencies, that I am sort of scared if one component blows up during an upgrade, how long it will take me to repair the damage. With Django, every component is developed and provided by the Django Project team and tested before being released. They are very independent in this regard, and I highly respect that independence. To that regard, I am going to put together a Django tutorial which mimics the Pyramid Wiki tutorial to display how much less code is required in Django, and how much more functionality can be given to the Wiki at the same time. Please check out this upcoming Tutorial and more in the Tutorials section of this website.