I’ve been working with django for 2 years now on various projects, recently i decided to give a try to pylons, here are some of my thoughts about the two.
First of all the two are fundamentally different, django is a bundle of tools that work nicely together, pylons is glue around your tools of choice. A good example here is a template engine. When creating a new pylons project it asks you what engine you want to use, making zero assumptions. Django comes with it’s own template engine to start with. Bunch of still in django.contrib depends on the django template tags. That means to retain basic django functionality (admin, comments, 3rd party reusable apps) on a different template engine you have to monkey-patch django :). As a side not until 1.2 the development was heavily slowed down by the incompatibility between jinja2 and django, .
Lesson here: use what django gives you or you’re in for lots of troubles
There is more than one side on the “django is a bundle” argument tho, let’s have a look at something as common as authentication. My goal was to secure the editing of blog posts on this blog. On pylons the process went like:
- google it
- look up the various auth libs out there
- decide on auth lib
- lookup basic example that auths from file
- lookup more complex example that auths from DB
The comparable process on django would be:
- google it
- look up basic example
This approach has the downside of locking you into one SQL row per user loosing the flexibility pylons approach offers. On the other side this is exactly what i wanted on all, but one, the projects i’ve done so far. As added bonus django also gives me the functional web interface for administering users out of the box.
Lesson here: in most cases the django assumptions offer more productivity than pylons pluggable infrastructure
There are more people using django out there. Some of the implications are more:
- 3rd party recipes and reusable code
- community support (irc)
- jobs / employees
Lesson here: size matters
What i can not leave out of this blog post is the pylons debug screen. Just like django it gives you the ability to see the context and variables of every line in the traceback. It also allows you to type the python code from web browser at ANY point from your traceback. Just to be clear, here are the steps i saved:
- find the line from traceback
- insert set_trace()
- re-run the request
- debug
- possibly find previous calling point, insert break point there and re-run the request
All that done straight from the browser, awesome!
Lesson here: pylons default debugger rocks
About almir