I've use Django, Pylongs, TG, and repoze.bfg. It's quite different. A vastly oversimplified metaphor would be unix to OSX. Django is a monolithic all in one environment where everything 'just works' together but is not useful outside of Django, and no part really really excels at its own job, while being good enough for Django. Pylons expects you to write a lot more glue, and works better if you anticipate hitting the wall with a Django component ( ie Django's ORM is not even close to SQLAlchemy ). Pylons tends to attract people who will be writing a complex app that they will run with for a long time, or be extending in their own way. If you think there is a good chance you might need to rip out own component to replace it with a tweaked one, or different version, it's a lot easier with Pylons. Pylons is also written from the ground up around WSGI, so if building app stacks out of WSGI is your thing, that is still easier in Pylons ( though possible in Django. It still feels a bit bolted on though ).
That said, I personally prefer repoze.bfg over all of them now. Also minimal, built on wsgi, but also built on the Zope Component Architecture ( just the ZCA, does not depend on the ZODB or Zope server). For really being able to reuse and extend your code, that ZCA infrastructure is the killer feature.
To be fair, I should point out that it's much easier to get new developers going on Django, and that the monolithic approach gives people a much better out-of-box experience. Just not my thing, I like Vim better than Eclipse too. ;-)
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).
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.
That said, I personally prefer repoze.bfg over all of them now. Also minimal, built on wsgi, but also built on the Zope Component Architecture ( just the ZCA, does not depend on the ZODB or Zope server). For really being able to reuse and extend your code, that ZCA infrastructure is the killer feature.