I'm begining a new webapp in Python. I've narrowed my choices down to Django and Pylons. What are the pros/cons of each?

+16  A: 

Django vs Pylons:

The versus link is dead.
I fixed it now.
+30  A: 

How experienced are you in Python? If the answer is "not very", I'd say to start with Django. If you're fairly experienced in python, you may want to look into Pylons. This isn't because Pylons is a lot harder to learn than Django, so much as it is that Pylons's biggest advantage lies in its ease of customization. But to really use that customizability, you've got to know a little bit more about what python software is out there. (This isn't to say that Django isn't customizable, either. It's just that Pylons seems to be more flexible in this respect).

The only other thing that jumps to mind immediately is that Django will automatically generate an administration section on your website for you, which is REALLY helpful.

Jason Baker
+5  A: 

Pylons is more based on flexibility and having the choice to use different components (like SQLObject or SQLAlchemy for ORM, Mako or Mighty por templates). Apart from this, it uses some things ported from Ruby on Rails, like Routes and WebHelper.

I think Pylons is a good choice if you want to see variety of styles and code, although I it may take you some time to get some speed using it.

+11  A: 

IMHO, if you want to have a lot of well-written docs for the most common things you might want to build, go for django. Using pylons is actually using the third-party components you can fit together. So you're not going to spend a lot of time on pylons' website, but on the ORM's website and the templating system's website etc.

Also, django now has a PONY And nothing can beat that!

+1 for the pony power! :)
Sorry, but Pylons and TurboGears both had [pony middleware][1] long before Django. TurboGears even had a Web 2.0-ized [pony screencast][2] as an early demo.[1]:[2]:
Matt Good
pylons documentation was the reason I started using it. It continues to do a good job of explaining the magic that is happening so that it is no longer magic to you. That's when you win.
Tom Willis
+3  A: 

Django also has a wide range of reusable apps, which you can use with modifications or as example to create something new. And of course, community matters! Django community much wider, this make big sense for beginners.

That's essentially why I chose Django. I'm new to Python and generally to web frameworks, but not new to web programming. I chose to start with Django due to the broader community, and availability of articles and assistance it brings.
Alex JL
+18  A: 

In my experience, when trying to build a very custom web site, I felt too restricted by Django. It seemed to be great for simple tasks, but Pylons gives me the flexibility to build custom things from the ground up. I agree about the learning curve though, as it will take a bit longer to learn the various modules available for use in Pylons than it will to read all the Django docs which are all in 1 place.

+1 Dunno about pylons, but I feel the same way about Django.
hasen j
+2  A: 

I am currently looking at Pylons for my work for two reasons. (1) Pylons has support for multiple databases and Django does not (within reason). (2) Mako and SQLAlchemy are both available to Pylons and they are both desirable to learn even outside of the web framework world.

Actually, within reason, Django does support multiple databases. PostgreSQL, MySQL, and Oracle.
Wrong kind of "multiple databases".
Aaron Gallagher
Django will support multiple databases as of version 1.2
Mark Stahler
+173  A: 

Disclaimer: I created Pylons.

It really depends on the type of application you're building. Both frameworks were originally made to solve different problems. Despite how far they've both come since their creation its still very useful to keep in mind the problems they were created to solve because many of those choices have guided further development.

Django was made for newspaper sites, not just a single newspaper (publishing) site, but for making entire sites quickly. They generally had a staff that needed to start pushing content into the system ASAP, even before the public version of the site might be done. This is still clearly reflected in Django as it has a very complete user-friendly admin interface for the staff to begin entering content.

At the time Django was made, SQLAlchemy wasn't around, and SQLObject was kind of... lacking, so Django has its own ORM. It's still lacking in many ways compared to SQLAlchemy, but it'll work just great for alot of people's needs.

Django also has the concept of 'apps', which are just directories inside a Django project that do a specific function for the site. This reflects the original creators needs to quickly share components of a site with other sites they made. For example, quickly adding comments, or reviews, to another Django site.

While you can use SQLAlchemy, or other template languages such as Mako, in Django, many of Django's strengths (the existing 'apps' you can re-use, the admin interface, parts of the form library) go up in smoke as soon as you use SQLAlchemy instead of Django's ORM.

Just like the Django authors made Django to scratch their particular itch, I made Pylons to scratch mine.

In my experience, creating sites is a very small portion of their life-span. I actually spend significantly more time maintaining a web application, or adding features to an existing one. So the first thing I wanted in the framework was common places to put the 'basics' of a web application, so that it'd be easier to maintain, and that if other people knew Pylons they'd have an easier time jumping in to help maintain a Pylons app.

For all the sites I've built, they generally involve very different database schemas and data back-ends, with little in common. So sharing 'apps' like Django does just isn't a priority, nor is it feasible given how different each app will actually be (you can't share parts requiring a specific concept of how users are handled if different apps need to handle them differently).

I also needed something small, that wasn't trying to run the show for me. I want to be able to go in and determine how something is going to respond without hoping the framework 'lets' me do it. For this reason, a Pylons app is a bit different from most frameworks, in that the project itself builds the application object, making it easy to get in and tweak and change any core bit as needed.

So the question someone trying to choose should be asking themselves, is what are they trying to build? Because that's really the best way to determine the appropriate framework to use for the task.

Also, at the moment, the Pylons Book is 100% up to date with Pylons, while Django's book has been updated for version 1.1 of Django.

Ben Bangert
Great reply. Its seldom an alternate framework author post an unbiased view point :)
I love the disclaimer.
le pylons cest moi :P
+7  A: 

I am not an experienced user and never claimed that I am, but for me - Pylons is the framework of choice.

If You have a little experience in python, You will catch the basics in about one, maybe two days. But after that time, You will feel like the one and only ruler of what You created. Everything is custom, You can change almost every elemnt, plus You will learn python and maybe other languages along the way.

We can compare Django and Pylons to Linux distros: for me, Django is like Ubuntu - easy, and works out of the box. On the other hand, I would compare Pylons to Archlinux, where everything depends from You.

As (almost) always in life, more work equals more fun and profit.

+9  A: 

I know django but after reading the answers to this question I decided to try pylons for a new project, and my opinion now is

  1. If in hurry use django
  2. If not in hurry use django
  3. In special cases where django doesn't suffices use pylons

Pylons is great but django is simpler integrated approach I think this article summarizes it very well

Anurag Uniyal
That article was awesome!
+12  A: 

Choice is demotivating. In a famous experiment researchers set up a table in a grocery store with six jars of jam and on a different day a table with 24 jars of jam. More people sampled from the table with more jam, but only 3% went on to buy jam. 30% of the people who stopped by the table with six jars of jam actually purchased jam.

Welcome to Pylons, a jam-packed web framework.

Pylons advertises the power of choice but implements a demotivating failure to design. As the Pylons developer you get to research and sort through an impressive number of bad choices (external projects) at almost every step of the process. First, choose your templating language and whether you want to use SQLAlchemy (a very good choice). paster create -t pylons project-name writes 38 files to your source tree. You get to read and understand all of these files before you really know which to edit. As a bonus, you get to maintain your own fork of the Pylons application template.

There are some application templates that provide even more files for you to fork but they are not very mature.

Pylons is tempting as the number two Python web framework as measured by tagged questions (~100 versus ~3000 for Django) and as a way to get SQLAlchemy support out of the box for your web application, but I've found it to be quite frustrating.

+4  A: 

While both are great frameworks and provide many benefits, you don't actually need either.

Here's what I use on Debian:

$aptitude install python-paste python-mako python-psycopg2

-- --
from paste.httpserver import serve
from paste.reloader import install
from lib.dispatcher import Dispatcher
serve(Dispatcher(), host='', port='8080', threadpool_workers=50, use_threadpool=True)

The dispatcher routes requests to various controller classes based on the url. The controllers use psycopg for the postgresql database and call mako templates and return the output.

+2  A: 

The joy of Django... It's easy to get going due to defined conventions and great documentation. When I feel the need, I still have the power to customize (i.e. use a second templating language such as Jinja2 and/or add in support for sqlalchemy). To me, that's the best of both worlds!

Michael LeValle
+3  A: 

My first Python framework was Pylons, this was several years ago. I don't know why I didn't select Django - I simply didn't like it after the first look.

But after one year of Pylons experience I had to use Django at my new job and you know... I found it very pleasant, good-documented and neatly structured.

At the moment I may say that all the Rails-related stuff (like WebHelpers and Routes), the needless complexity of Pylons' structure and configuration, the ORMs (sqlalchemy and SQLObject) look ugly compare to corresponding solutions in Django.


You've been blatantly plagiarized! I happened to be googling django vs. pylons today and found your excellent post above and then this other post ( which is a very thinly reconstituted version of your post, yet claimed to be original. Pathetic. Anyway, thanks for the info you've shared above (and for inventing pylons!).