Django vs Flask vs Pyramid: Choosing a Python Web Framework (2024)

TL;DR: Pyramid, Django, and Flask are all excellent frameworks, and choosing just onefor a project is hard. We'll see working apps with identical functionality in all three frameworks to make comparing the three easier. Skip to Frameworks in Action^[1]

1 Introduction

The world of Python web frameworks is full of choices. Django, Flask, Pyramid,Tornado, Bottle, Diesel, Pecan, Falcon, and many more are competing fordeveloper mindshare. As a developer you want to cut the legions of options downto the one that will help you finish your project and get on to the Next BigThing (tm). We'll focus on Flask, Pyramid, and Django. Their ideal cases spanfrom micro-project to enterprise-size web service.

To help make the choice between the three easier (or at least more informed),we'll build the same application in each framework and compare the code,highlighting the strengths and weaknesses of each approach. If you just wantthe code, skip straight to Frameworks in Action or view the code onGithub.

Flask is a "microframework" primarily aimed at small applications with simplerrequirements. Pyramid and Django are both aimed at larger applications, buttake different approaches to extensibility and flexibility. Pyramid targetsflexibility and lets the developer use the right tools for their project. Thismeans the developer can choose the database, URL structure, templating style,and more. Django aims to include all the batteries a web application will needso developers need only open the box and start working, pulling in Django'smany modules as they go.

Django includes an ORM out of the box, while Pyramid and Flask leaveit to the developer to choose how (or if) they want their data stored. Themost popular ORM for non-Django web applications is SQLAlchemy by far,but there are plenty of other options from DynamoDB andMongoDB to simple local persistence like LevelDB or plainSQLite. Pyramid is designed to use any persistence layer, evenyet-to-be-invented ones.

2 About the Frameworks

Django's "batteries included" approach makes it easy for developers who knowPython already to dive in to web applications quickly without needing to makea lot of decisions about their application's infrastructure ahead of time.Django has for templating, forms, routing, authentication, basic databaseadministration, and more built in. In contrast, Pyramid includes routing andauthentication, but templating and database administration require externallibraries.

The extra work up front to choose components for Flask and Pyramid apps yieldsmore flexibility for developers whose use case doesn't fit a standard ORM, orwho need to interoperate with different workflows or templating systems.

Flask, the youngest of the three frameworks, started in mid-2010. The Pyramidframework began life in the Pylons project and got the name Pyramidin late 2010, though the first release was in 2005. Django had its firstrelease in 2006, shortly after the Pylons (eventually Pyramid) project began.Pyramid and Django are extremely mature frameworks, and have accumulatedplugins and extensions to meet an incredibly large range of needs.

Though Flask has a shorter history, it has been able to learn from frameworksthat have come before and has set its sights firmly on small projects. It isclearly used most often in smaller projects with just one or two functions.One such project is httpbin, a simple (but extremely powerful)helper for debugging and testing HTTP libraries.

3 Community

The prize for most active community goes to Django with 80,000 StackOverflowquestions and a healthy set of blogs from developers and power users. TheFlask and Pyramid communities aren't as large, but their communities are quiteactive on their mailing lists and on IRC. With only 5,000 StackOverflowquestions tagged, Flask is 15x smaller than Django. On Github, they have anearly identical number of stars with 11,300 for Django, and 10,900 for Flask.

All three frameworks are available under BSD-derived permissive licenses. BothFlask's and Django's licenses are 3-clause BSD, whilePyramid's Repoze Public License RPL is a derivative of the 4-clause BSDlicense.

4 Bootstrapping

Django and Pyramid both come with bootstrapping tools built in. Flask includesnothing of the sort because Flask's target audience isn't trying to buildlarge MVC applications.

4.1 Flask

Flask's Hello World app has to be the simplest out there, clocking in at apuny 7 lines of code in a single Python file.

# from http://flask.pocoo.org/ tutorialfrom flask import Flaskapp = Flask(__name__)@app.route("/") # take note of this decorator syntax, it's a common patterndef hello(): return "Hello World!"if __name__ == "__main__": app.run()

This is why there aren't bootstrapping tools for Flask: there isn't a demandfor them. From the above Hello World featured on Flask's homepage, a developerwith no experience building Python web applications can get hackingimmediately.

For projects that need more separation between components, Flask hasblueprints. For example, you could structure your Flask app withall user-related functions in users.py and your sales-related functions inecommerce.py, then import them and add them to your app in site.py. Wewon't go over this functionality, as it's beyond the needs of our demo app.

4.2 Pyramid

Pyramid's bootstrapping tool is called pcreate which is part of Pyramid.Previously the Paste suite of tools provided bootstrapping forbut has since been replaced with a Pyramid-specific toolchain.

$ pcreate -s starter hello_pyramid # Just make a Pyramid project

Pyramid is intended for bigger and more complex applications than Flask.Because of this, its bootstrapping tool creates a bigger skeleton project. Italso throws in basic configuration files, an example template, and the filesto package your application for uploading to the Python Package Index.

hello_pyramid├── CHANGES.txt├── development.ini├── MANIFEST.in├── production.ini├── hello_pyramid│ ├── __init__.py│ ├── static│ │ ├── pyramid-16x16.png│ │ ├── pyramid.png│ │ ├── theme.css│ │ └── theme.min.css│ ├── templates│ │ └── mytemplate.pt│ ├── tests.py│ └── views.py├── README.txt└── setup.py

As in the rest of the framework, Pyramid's bootstrapper is incrediblyflexible. It's not limited to one default application; pcreate can use anynumber of project templates. Included in pcreate there is the "starter"template we used above, along with SQLAlchemy- and ZODB-backedscaffold projects. On PyPi it's possible to find ready-made scaffolds forGoogle App Engine, jQuery Mobile, Jinja2templating, modern frontend frameworks, and many more.

4.3 Django

Django also has its own bootstrapping tool built in as a part of django-admin.

django-admin startproject hello_djangodjango-admin startapp howdy # make an application within our project

We can already see one of the ways Django differs from Pyramid. Djangoseparates a project into individual applications, where Pyramid and Flaskexpect a project to be a single "application" with several views or models.It's possible to replicate the project/app distinction in Flask and Pyramid,but the notion does not exist by default.

hello_django├── hello_django│ ├── __init__.py│ ├── settings.py│ ├── urls.py│ └── wsgi.py├── howdy│ ├── admin.py│ ├── __init__.py│ ├── migrations│ │ └── __init__.py│ ├── models.py│ ├── tests.py│ └── views.py└── manage.py

By default Django only includes empty model and template files, so a new usersees a bit less example code to start out. It also (unfortunately) leaves thechoice of how to distribute their application to the developer.

The downside of the bootstrap tool not guiding users to package their apps isthat novice users won't. If a developer hasn't packaged an app before, they'llfind themselves rudely surprised upon their first deploy. Projects with alarge community like django-oscar are packaged and available on PyPi,but smaller projects on Github often to lack uniform packaging.

5 Templating

Just having a Python application that can respond to HTTP requests is a greatstart, but it's a good bet that most of your users won't be interested inusing curl to interact with your web app. Fortunately, all three contendersprovide an easy way to fill in HTML with custom info, and let folks enjoy yourswanky Bootstrap frontend.

Templating lets you inject dynamic information directly into your page withoutusing making AJAX requests. This is nice from a user experience perspectivesince you only need to make one round-trip to get the full page and all itsdynamic data. This is especially important on mobile sites where round tripscan take multiple seconds.

All the templating options we'll see rely on a "context" that provides thedynamic information for the template to render into HTML. The simplest usecase for a template would be to populate a logged-in user's name to greet themproperly. It would be possible to use AJAX to get this sort of dynamicinformation, but requiring a whole call just to fill in a user's name would bea bit excessive when templates are this easy.

5.1 Django

Our example use case is about as easy as it gets, assuming that we have auser object that has a fullname property containing a user's name. InPython we'd pass the current user to the template like so:

def a_view(request): # get the logged in user # ... do more things return render_to_response( "view.html", {"user": cur_user} )

Populating the template context is as simple as passing a dictionary of thePython objects and data structures the template should use. Now we need torender their name to the page, just in case they forget who they are.

<!-- view.html --><div class="top-bar row"> <div class="col-md-10"> <!-- more top bar things go here --> </div> {% if user %} <div class="col-md-2 whoami"> You are logged in as {{ user.fullname }} </div> {% endif %}</div>

First, you'll notice the {% if user %} construct. In Django templates {%is used for control statements like loops and conditionals. The if userstatement is there to guard against cases where there is not a user. Anonymoususers shouldn't see "you are logged in as" in the site header.

Inside the if block, you can see that including the name is as simple aswrapping the property we want to insert in {{ }}. The {{ is used to insertactual values into the template, such as {{ user.fullname }}.

Another common use for templates is displaying groups of things, like theinventory page for an ecommerce site.

def browse_shop(request): # get items return render_to_response( "browse.html", {"inventory": all_items} )

In the template we can use the same {% to loop over all the items in theinventory, and to fill in the URL to their individual page.

{% for widget in inventory %} <li><a href="/widget/{{ widget.slug }}/">{{ widget.displayname }}</a></li>{% endfor %}

To do most common templating tasks, Django can accomplish the goal with just afew constructs, making it easy to get started.

5.2 Flask

Flask uses the Django-inspired Jinja2 templating language by defaultbut can be configured to use another language. A programmer in a hurrycouldn't be blamed for mixing up Django and Jinja templates. In fact, both theDjango examples above work in Jinja2. Instead of going over the same examples,let's look at the places that Jinja2 is more expressive than Djangotemplating.

Both Jinja and Django templates provide a feature called filtering, where alist can be passed through a function before being displayed. A blog thatfeatures post categories might make use of filters to display a post'scategories in a comma-separated list.

<!-- Django --><div class="categories">Categories: {{ post.categories|join:", " }}</div><!-- now in Jinja --><div class="categories">Categories: {{ post.categories|join(", ") }}</div>

In Jinja's templating language it's possible to pass any number of argumentsto a filter because Jinja treats it like a call to a Python function, withparenthesis surrounding the arguments. Django uses a colon as a separatorbetween the filter name and the filter argument, which limits the number ofarguments to just one.

Jinja and Django for loops are also similar. Let's see where they differ. InJinja2, the for-else-endfor construct lets you iterate over a list, but alsohandle the case where there are no items.

{% for item in inventory %}<div class="display-item">{{ item.render() }}</div>{% else %}<div class="display-warn"><h3>No items found</h3><p>Try another search, maybe?</p></div>{% endfor %}

The Django version of this functionality is identical, but usesfor-empty-endfor instead of for-else-endfor.

{% for item in inventory %}<div class="display-item">{{ item.render }}</div>{% empty %}<div class="display-warn"><h3>No items found</h3><p>Try another search, maybe?</p></div>{% endfor %}

Other than the syntactic differences above, Jinja2 provides more control overits execution environment and advanced features. For example, it's possible todisable potentially dangerous features to safely execute untrusted templates,or to compile templates ahead of time to ensure their validity.

5.3 Pyramid

Like Flask, Pyramid supports many templating languages (including Jinja2 andMako) but ships with one by default. Pyramid uses Chameleon, animplementation of ZPT (the Zope Page Template) templating language.Let's look back at our first example, adding a user's name to the top bar ofour site. The Python code looks much the same except that we don't need toexplicitly call a render_template function.

@view_config(renderer='templates/home.pt')def my_view(request): # do stuff... return {'user': user}

But our template looks pretty different. ZPT is an XML-based templatingstandard, so we use XSLT-like statements to manipulate data.

<div class="top-bar row"> <div class="col-md-10"> <!-- more top bar things go here --> </div> <div tal:condition="user" tal:content="string:You are logged in as ${user.fullname}" class="col-md-2 whoami"> </div></div>

Chameleon actually has three different namespaces for template actions. TAL(template attribute language) provides basics like conditionals, basic stringformatting, and filling in tag contents. The above example only made use ofTAL to complete its work. For more advanced tasks, TALES and METAL arerequired. TALES (Template Attribute Language Expression Syntax) providesexpressions like advanced string formatting, evaluation of Python expressions,and importing expressions and templates.

METAL (Macro Expansion Template Attribute Language) is the most powerful (andcomplex) part of Chameleon templating. Macros are extensible, and can bedefined as having slots that are filled when the macro is invoked.

6 Frameworks in Action

For each framework let's take a look at making an app called wut4lunch, asocial network to tell the whole internet what you ate for lunch. Free startupidea right there, totally a gamechanger. The application will be a simpleinterface that allows users to post what they had for lunch and to see a listof what other users ate. The home page will look like this when we're done.

6.1 Demo App with Flask

The shortest implementation clocks in at 34 lines of Python and a single 22line Jinja template. First we have some housekeeping tasks to do, likeinitializing our app and pulling in our ORM.

from flask import Flask# For this example we'll use SQLAlchemy, a popular ORM that supports a# variety of backends including SQLite, MySQL, and PostgreSQLfrom flask.ext.sqlalchemy import SQLAlchemyapp = Flask(__name__)# We'll just use SQLite here so we don't need an external databaseapp.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///test.db'db = SQLAlchemy(app)

Now let's take a look at our model, which will remain almost the same for ourother two examples as well.

class Lunch(db.Model): """A single lunch""" id = db.Column(db.Integer, primary_key=True) submitter = db.Column(db.String(63)) food = db.Column(db.String(255))

Wow, that's pretty easy. The hardest part was finding the right SQLAlchemydata types and picking a length for our String fields in thedatabase. Using our models is also extremely simple, thanks to the SQLAlchemyquery syntax we'll see later.

Building our submission form is just as easy. After importingFlask-WTForms and the correct field types, you can see the formlooks quite a bit like our model. The main difference is the new submit buttonand prompts for the food and submitter name fields.

The SECRET_KEY field in the app config is used by WTForms to createCSRF tokens. It is also used by itsdangerous (includedin Flask) to sign cookies and other data.

from flask.ext.wtf import Formfrom wtforms.fields import StringField, SubmitFieldapp.config['SECRET_KEY'] = 'please, tell nobody'class LunchForm(Form): submitter = StringField(u'Hi, my name is') food = StringField(u'and I ate') # submit button will read "share my lunch!" submit = SubmitField(u'share my lunch!')

Making the form show up in the browser means the template has to have it.We'll pass that in below.

from flask import render_template@app.route("/")def root(): lunches = Lunch.query.all() form = LunchForm() return render_template('index.html', form=form, lunches=lunches)

Alright, what just happened? We got a list of all the lunches that havealready been posted with Lunch.query.all(), and instantiated a form to letthe user post their own gastronomic adventure. For simplicity, the variablesare passed into the template with the same name, but this isn't required.

<html><title>Wut 4 Lunch</title><b>What are people eating?</b><p>Wut4Lunch is the latest social network where you can tell all your friendsabout your noontime repast!</p>

Here's the real meat of the template, where we loop through all the lunchesthat have been eaten and display them in a <ul>. This almost identical tothe looping example we saw earlier.

<ul>{% for lunch in lunches %}<li><strong>{{ lunch.submitter|safe }}</strong> just ate <strong>{{ lunch.food|safe }}</strong>{% else %}<li><em>Nobody has eaten lunch, you must all be starving!</em></li>{% endfor %}</ul><b>What are YOU eating?</b><form method="POST" action="/new"> {{ form.hidden_tag() }} {{ form.submitter.label }} {{ form.submitter(size=40) }} <br/> {{ form.food.label }} {{ form.food(size=50) }} <br/> {{ form.submit }}</form></html>

The <form> section of the template just renders the form labels and inputsfrom the WTForm object we passed into the template in the root() view. Whenthe form is submitted, it'll send a POST request to the /new endpoint whichwill be processed by the function below.

from flask import url_for, redirect@app.route(u'/new', methods=[u'POST'])def newlunch(): form = LunchForm() if form.validate_on_submit(): lunch = Lunch() form.populate_obj(lunch) db.session.add(lunch) db.session.commit() return redirect(url_for('root'))

After validating the form data, we put the contents into one of our Modelobjects and commit it to the database. Once we've stored the lunch in thedatabase it'll show up in the list of lunches people have eaten.

if __name__ == "__main__": db.create_all() # make our sqlalchemy tables app.run()

Finally, we have to do a (very) little bit of work to actually run our app.Using SQLAlchemy we create the table we use to store lunches, then startrunning the route handlers we wrote.

6.2 Demo App with Django

The Django version of wut4lunch is similar to the Flask version, but is spreadacross several files in the Django project. First, let's look at the mostsimilar portion: the database model. The only difference between this and theSQLAlchemy version is the slightly different syntax for declaring a databasefield that holds text.

# from wut4lunch/models.pyfrom django.db import modelsclass Lunch(models.Model): submitter = models.CharField(max_length=63) food = models.CharField(max_length=255)

On to the form system. Unlike Flask, Django has a built-in form system that wecan use. It looks much like the WTForms module we used in Flask with differentsyntax.

from django import formsfrom django.http import HttpResponsefrom django.shortcuts import render, redirectfrom .models import Lunch# Create your views here.class LunchForm(forms.Form): """Form object. Looks a lot like the WTForms Flask example""" submitter = forms.CharField(label='Your name') food = forms.CharField(label='What did you eat?')

Now we just need to make an instance of LunchForm to pass in to ourtemplate.

lunch_form = LunchForm(auto_id=False)def index(request): lunches = Lunch.objects.all() return render( request, 'wut4lunch/index.html', { 'lunches': lunches, 'form': lunch_form, } )

The render function is a Django shortcut that takes the request, thetemplate path, and a context dict. Similar to Flask's render_template, butit also takes the incoming request.

def newlunch(request): l = Lunch() l.submitter = request.POST['submitter'] l.food = request.POST['food'] l.save() return redirect('home')

Saving the form response to the database is different, instead of using aglobal database session Django lets us call the model's .save() method andhandles session management transparently. Neat!

Django provides some nice features for us to manage the lunches that usershave submitted, so we can delete lunches that aren't appropriate for our site.Flask and Pyramid don't provide this automatically, and not having to writeYet Another Admin Page when making a Django app is certainly a feature.Developer time isn't free! All we had to do to tell Django-admin about ourmodels is add two lines to wut4lunch/admin.py.

from wut4lunch.models import Lunchadmin.site.register(Lunch)

Bam. And now we can add and delete entries without doing any extra work.

Lastly, let's take a look at the differences in the homepage template.

<ul>{% for lunch in lunches %}<li><strong>{{ lunch.submitter }}</strong> just ate <strong>{{ lunch.food }}</strong></li>{% empty %}<em>Nobody has eaten lunch, you must all be starving!</em>{% endfor %}</ul>

Django has a handy shortcut for referencing other views in your pages. Theurl tag makes it possible for you to restructure the URLs your applicationserves without breaking your views. This works because the url tag looks upthe URL of the view mentioned on the fly.

<form action="{% url 'newlunch' %}" method="post"> {% csrf_token %} {{ form.as_ul }} <input type="submit" value="I ate this!" /></form>

The form is rendered with different syntax, and we need to include a CSRFtoken manually in the form body, but these differences are mostly cosmetic.

6.3 Demo App with Pyramid

Finally, let's take a look at the same program in Pyramid. The biggestdifference from Django and Flask here is the templating. Changing the Jinja2template very slightly was enough to solve our problem in Django. Not so thistime, Pyramid's Chameleon template syntax is more reminiscent of XSLTthan anything else.

<!-- pyramid_wut4lunch/templates/index.pt --><div tal:condition="lunches"> <ul> <div tal:repeat="lunch lunches" tal:omit-tag=""> <li tal:content="string:${lunch.submitter} just ate ${lunch.food}"/> </div> </ul></div><div tal:condition="not:lunches"> <em>Nobody has eaten lunch, you must all be starving!</em></div>

Like in Django templates, a lack of the for-else-endfor construct makes thelogic slightly more verbose. In this case, we end up with if-for andif-not-for blocks to provide the same functionality. Templates that use XHTMLtags may seem foreign after using Django- and AngularJS-style templates thatuse {{ or {% for control structures and conditionals.

One of the big upsides to the Chameleon templating style is that your editorof choice will highlight the syntax correctly, since the templates are validXHTML. For Django and Flask templates your editor needs to have support forthose templating languages to highlight correctly.

<b>What are YOU eating?</b><form method="POST" action="/newlunch"> Name: ${form.text("submitter", size=40)} <br/> What did you eat? ${form.text("food", size=40)} <br/> <input type="submit" value="I ate this!" /></form></html>

The form rendering is slightly more verbose in Pyramid because thepyramid_simpleform doesn't have an equivalent to Django forms' form.as_ulfunction, which renders all the form fields automatically.

Now let's see what backs the application. First, we'll define the form we needand render our homepage.

# pyramid_wut4lunch/views.pyclass LunchSchema(Schema): submitter = validators.UnicodeString() food = validators.UnicodeString()@view_config(route_name='home', renderer='templates/index.pt')def home(request): lunches = DBSession.query(Lunch).all() form = Form(request, schema=LunchSchema()) return {'lunches': lunches, 'form': FormRenderer(form)}

The query syntax to retrieve all the lunches is familiar from Flask becauseboth demo applications use the popular SQLAlchemy ORM to providepersistent storage. In Pyramid lets you return your template's contextdictionary directly instead of needing to call a special render function.The @view_config decorator automatically passes the returned context to thetemplate to be rendered. Being able to skip calling the render method makesfunctions written for Pyramid views easier to test, since the data they returnisn't obscured in a template renderer object.

@view_config(route_name='newlunch', renderer='templates/index.pt', request_method='POST')def newlunch(request): l = Lunch( submitter=request.POST.get('submitter', 'nobody'), food=request.POST.get('food', 'nothing'), ) with transaction.manager: DBSession.add(l) raise exc.HTTPSeeOther('/')

Form data is easy to retrieve from Pyramid's request object, whichautomatically parsed the form POST data into a dict that we can access. Toprevent multiple concurrent requests from all accessing the database at thesame time, the ZopeTransactions module provides context managersfor grouping database writes into logical transactions and prevent threads ofyour application from stomping on each others' changes, which can be a problemif your views share a global session and your app receives a lot of traffic.

7 Summary

Pyramid is the most flexible of the three. It can be used for small apps aswe've seen here, but it also powers big-name sites like Dropbox. Open Sourcecommunities like Fedora choose it for applications like theircommunity badges system, which receives information about events frommany of the project's tools to award achievement-style badges to users. One ofthe most common complaints about Pyramid is that it presents so many options itcan be intimidating to start a new project.

By far the most popular framework is Django, and the list of sites that use itis impressive. Bitbucket, Pinterest, Instagram, and The Onion use Django forall or part of their sites. For sites that have common requirements, Djangochooses very sane defaults and because of this it has become a popular choicefor mid- to large-sized web applications.

Flask is great for developers working on small projects that need a fast wayto make a simple, Python-powered web site. It powers loads of small one-offtools, or simple web interfaces built over existing APIs. Backend projectsthat need a simple web interface that is fast to develop and will requirelittle configuration often benefit from Flask on the frontend, likejitviewer which provides a web interface for inspecting PyPyjust-in-time compiler logs.

All three frameworks came up with a solution to our small list ofrequirements, and we've been able to see where they differ. Those differencesaren't just cosmetic, and they will change how you design your product and howfast you ship new features and fixes. Since our example was small, we've seenwhere Flask shines and how Django can feel clunky on a small scale. Pyramid'sflexibility didn't become a factor because our requirements stayed the same,but in the real world new requirements are thrown in constantly.

7.1 Credits

Logos in the title image are from theFlaskDjango andPyramid project websites.

This article owes many thanks to its reviewers, Remy DeCausemaker, RossDelinger, and Liam Middlebrook, for tolerating many early drafts.

In its current form this article incorporates comments and corrections fromAdam Chainz, bendwarn, Sergei Maertens, Tom Leo, and wichert. (alphabeticalorder)