The problem with comparing Pylons to Django

...is that my experiences with Pylons are from nearly two years ago. My experiences with Django are ongoing. So any comparison I do will be completely unfair. But lets do a little anyway because there are some issues I want to raise.

ORM non-Issue
I don't have any issues here with either framework. At the time played with Pylons I think it used SQLObject. Now you can use SQLAlchemy. If you want, Pylons can also handle Python's DB-API if you want a bit of pain with your SQL. Django has its own ORM. Personally, I'm happy with any ORM to handle all the mundane tasks, and all three ORMs have good enough documentation to make working with them a snap. So ORM is a non-issue.

Routing non-Issue
Pylons routing of URLs to methods was easy. Django has an easy method too. I'm sure some folks might take issue with some of the finer points but I haven't ran into any killer issues myself. I think both let us specify things ending with slashes, or '.php' if we have a sense of humor. So routing is a non-issue.

Django Templates versus Myghty/Mako
The problem is my own lack of discipline. It can be so easy to start adding in more and more logic into your views. I would rather call python modules with python methods written in python then cook up fancy logic in a view-focused templating engine. Yet again and again I do the stupid, and mix my content with presentation. So I want a templating system that limits what I can do with it.

When I did Pylons the default templating system was Myghty, patterned after a Perl library called html::mason. I did not like Myghty. Since then, Pylons adopted Mako. The same things that made me not like Myghty appear to be in Mako. Too much power! I can mix my business logic code too easily with the view stuff.

I like Django templates because it has good, hard limits on what you can do. You aren't cooking up creative ways to do logic in views. You are just simply writing views. In return, it gives you a bunch of default utility methods/filters that do a bunch of repetitive work.

A common alternative with Django is Jinja templates. I think Jinja might give application developers Myghty/Mako like power. So I'm not very interested in Jinja.

Django versus Pylons Documentation
I like good on-line documentation. Its very hard to do, and Django has done a smashing job with tutorials and on-line books. Pylons has some really good stuff, and I know that they've improved, but they are still not there with Django.

Admin Interface
So I create an application and have a table with 5 status values. The application goes to production. Turns out I mispelled a status title and it needs to be fixed.

In Django I log in as an admin, go to the errant record, and fix it. To make that work I just added an internal class to the Status model.

In Pylons (and I might be wrong), I can't do this. I either have to log into my database directly, or write a snippet of code to correct the problem, or code in an administrative module myself.

Summary
This comparison was totally unfair. I'm skipping a lot of wonderful things about Pylons. Things like Pylon's unbelievable flexibility in choosing components, the rails-like webhelpers, and the collective smarts of the people who work on the project. Or its close friendship with the latest versions of Turbogears, which probably smashes the admin interface issue right out of the ballpark.

So, in conclusion I'll play it completely safe and say that Django and Pylons are both good stuff. I just prefer working with Django.

Playing with Django

I've been playing with Django over the past few days. I'm not going to compare it to Plone or Zope. But I will happily compare it to Pylons. Ready?

Django is easier than Pylons.

There. That sums it up.

Easy, intuitive, and fun.

Pylons vs Django

I like the interior workings of Pylons, I really do. But if I want to do SQL based crud apps then Django is simply stronger. That strength is what drew me to TurboGears for a bit before parts of TurboGears annoyed me. Pylons just lacks a lot of the things that I want, like built-in auth . Sure, I can roll my own, but I'm lazy. Of course, Django is really meant for the CRUD sort of thing, and I wonder how good it would be beyond that avenue.

Note - I'll be expanding on this over time.

Update: My problematic comparison of Pylons vs Django.

Python Tips ahoy!

On the eve of Talk Like a Pirate Day, I am announcing a new personal project. A little site I'm going to call pytips, Python Tips, Yellow Monkey Land, or maybe something else. Its going to serve up recipes and tips for Python, and eventually other languages as well.

So why am I doing this?

Four reasons:

1. I think the Python community could be well served by such a site.
2. I want to practice in another framework besides Zope and Plone.
3. I need to keep my relational database skills from getting rusty.
4. Sounds like fun!

I'm going to do this in Pylons. I thought about Django, and maybe I'll make a port of it at some point. Shouldn't be too hard, right?

TurboGears merges with Pylons

I'm not an expert on either. In 2006 I spent about 4 or 5 weeks working with Pylons. A couple months later, I spent a couple weeks playing with TurboGears. Both were very interesting. I really tried to like Pylons but hated the Myghty which was what you had to play with via views. TurboGears back end wasn't as much fun as Pylons, but the front end used Kid as the template language for views.

That said, both frameworks really embodied things I like. They employed NIH and DRY all over the place with a vengeance. Sure, Django is a bit 'hip', but nix the scaffolding and all you have is Yet-Another-*SP-Template-Language combined with non-Pythonisms in a not-quite-RoR framework.

Well, once the Pylons and TurboGears marriage happens, Python's choice of quality frameworks will be down by one, but in a good way. Pylons will do the backend and you can load in TurboGears to be the front end. And with use of Genshi as the template attribute language. Yeah, Genshi isn't TAL, but it isn't that far off.

Links of interest:
http://compoundthinking.com/blog/index.php/2007/06/27/turbogears-11-and-beyond/
http://www.blueskyonmars.com/2007/06/27/turbogears-2-a-reinvention-and-back-to-its-roots/