[shazow]

I think of it this way: Django was built by a bunch of people with some specific goal in mind (make building a CMS super easy). For the most part, the same developers who built the ORM also built the templating language and the glue and the admin generator, and the auth system, etc.

Pylons was built by a bunch of people with different goals in mind. One was to make an awesome ORM. Another was to make a kickass templating language[1]. The purpose of Pylons is to make it easy to integrate your choice of optimal components into a web framework with reasonable ease.

Yes, if you're going to deviate from the defaults things may not work "out of the box" like Django, and you might not get a default auth system and an admin panel (could use something like repoze). While it'll take you longer to build the initial prototype in the first week, you wont hit that wall of "why do I have to put code in 4 places to add a template tag?" or "why am I getting weird PYTHONPATH-related side effects from using settings.py?" or "oh well, I guess I just wont use joins."

The ramp-up time/results curve of Pylons is steeper than Django's, but it stays relatively steady throughout your project, whereas a monolithic framework will get more and more in your way over time until you realize you've slowly dismantled the entire framework and reinvented Pylons.

[1] Incidentally, both SQLAlchemy and Mako Templates are founded by the same person, but historically Pylons has defaulted to whatever "the best" package was (SQLObject and Kid, a few years ago).

[jokull]

That's a good point about the Django honeymoon period before you hit all those little things like a proper multi environment settings.py schema. Once you're over those and start reading the Django code it becomes even more productive.