

Why I switched to Pylons after using Django for six months - dryicerx
http://www.mutualinformation.org/2010/03/why-i-switched-to-pylons-after-using-django-for-six-months/

======
idan
It seems like a lot of people get frustrated with Django because it isn't the
Framework for Copy & Paste Coders Who Like to be Spoonfed.

To some degree, this is a failure of the Django community's messaging. Django
is highly modular and, if anything, disassembles gracefully as you start
running into more complex scenarios (even more so in 1.2 than 1.1).

It's best to think of Django as a robust set of wheels you don't have to
reinvent for each new site you build, and a toolkit for building new wheels
you can not-reinvent next time around.

All of the above is painfully obvious to anybody who has spent a decent amount
of time with Django, but might not be so clear to somebody just finding their
way or using Django in a limited fashion. I'm sad to see that somebody had a
poor experience with Django, but this post is basically a lot of whining about
an inability to figure things out and use the framework as intended.

~~~
mgrouchy
I think your sentiment here is pretty correct. We have been using Django to
build SWIX ( <http://www.swixhq.com> ) and for the most part we find Django to
be a blessing. It does much of the heavy lifting and helps us keep all our
code modular and loosely coupled(at least when we are doing it right).

~~~
enjo
I concur.

I've built one very complex site using Django, and it's worked great.

For the authors specific complaints:

\- We found a nice reusable app. for recpatcha that basically just boils the
whole thing down to a form field. It works flawlessly. \- I implemented
twitter/facebook connect integration with no issues (all using the standard
auth system, and two apps) \- We've done things like dynamic custom forms that
work just beautifully.

It's a pretty long list of things that we've been able to accomplish with
Django. We're really happy with it, particularly since the 1.1 release. It has
a ton of flexibility, while still virtually automating most of the things we
do often.

It's certainly not turn-key, but we've done this without modifying one line of
django code.

In the near future I'm hoping to be able to take some time to open source some
of this work.

------
matrix
I've built a couple of reasonably complex Djamgo apps, and as much as I like
Django, all the points author makes are very true. That said, by the time you
have swapped out the template language and the ORM you are basically no longer
using Django; I think it's fair to say that if find yourself needing to do
those things, you're much better off with Pylons.It's a question of the right
tool for the job.

I do agree heartily that Django apps are not an effective level of abstraction
as on might hope. Personally I usually just stick to using various libraries
and writing my own code to do the Django-specific parts.

~~~
anthonyb
I just switched the other way - from Pylons to Django - for a work project,
for pretty much exactly the same reasons that he describes - inflexibility. In
my case, lots of boilerplate for admin screens plus SQLAlchemy felt like too
much magic. Particularly when trying to run functionality tests against my
app, there were a few too many weird errors, with no obvious way to fix them
(the solution was normally to move the database commit around), when the
application worked fine. Django tests on the other hand, Just Work(tm).

So far I haven't run into any lack of flexibility on Django's part, and I've
been using it for fairly serious stuff (mainly as a general-purpose CMS, heavy
admin screen work). From the look of the original author's sites, the things
that he's doing aren't too different, so I'm not sure what the problem is.
Perhaps he just prefers the way Pylons does things?

~~~
mcav
It sounds like you had issues with SQLAlchemy, not Pylons.*

If you take care to understand SQLAlchemy well, it won't get in your way
either.

*(I concede that Pylons doesn't have a good automated admin feature.)

~~~
anthonyb
I think it was more that the automated web testing part of Pylons wasn't
particularly well integrated with SQLAlchemy. So (eg.) it's basically
impossible (AFAICT) to populate the database with preexisting data and then
directly call the controllers, since when you commit the data in your
controller, you can't access the database afterwards when you get back to your
controller. Instead, you get lots of odd tracebacks - things like "Instance
<Foo at 0x103779f90> is not bound to a Session". It also means that you can't
do rollback type testing - you have to stick different data in, or blow it all
away and recreate it manually.

Django on the other hand, has fixtures, which you can create from your
existing database, and use rollbacks, so they're really fast. Combine that
with the test client, and I can just write my test cases and forget about
setting stuff up. People often go on about Django's admin interface, but I
find that the rest of the framework is written to the same sort of standard,
so there are lots of hidden gems (like fixtures) just waiting for you to find
them.

------
zain
Wow. In summary, he switched from Django to Pylons because:

    
    
      - He couldn't figure out how to modify his Pinax project
      - He couldn't get django-openid to work
      - There's no debugger on Django exception pages
      - Something about magic imports?
    

You don't have to fork Pinax to add/remove apps to it. You don't have to fork
django-openid to use it in your project, just override the templates.
Recaptcha fits into the app model very easily: it's just another auth backend.
You can get a debugger on your exception pages by installing django-
extensions.

~~~
johnthedebs
As a Django developer myself, I totally agree with some of his frustrations.
For example one _very_ common problem I run into with Django is that a typo in
a urls.py file will manifest itself as a URL reversal problem with the first
attempt at URL reversal. The error always point to the same file and it's
never the file with the problem, or even the same type of file. Not helpful.

While I agree that the problems could have been worked out with more knowledge
of the framework, it doesn't help to gloss over the issues. For almost all of
the problems he mentioned, Django's got a lot of room for improvement and
especially those who love it should admit that.

~~~
rbanffy
It should be possible to add a pdb.set_trace() or ipdb.set_trace() to the part
of Django that traverses the URL tree. Then it should be possible to watch
every URL be evaluated until one matches your request.

Don't ask me where it is, but, if you find it, it's worthy of a blog post ;-)

------
theli0nheart
The debugger he's so fond of is actually the Paste debugger
(paste.exceptions.errormiddleware.ErrorMiddleware). See
<http://gist.github.com/326254> on how to use it with Django WSGI deployments.

Secondly, Django is nearly unparalleled when it comes to CMS-based work. It
probably is the wrong choice if you're looking to build the next Google, but
for anything involving a system where the administrators are computer
illiterate, it's always a winner.

As for the entire reusable apps thing, I have to agree. It's good for
namespacing, but other than that, it doesn't have many benefits.

~~~
swah
So, how do I build the next Google?

------
vanschelven
Just spent a week refactoring our Django projects into apps. Nice timing.

The more I think about it, the less sure I am that the django-app is a good
model for any organisation of code (not just third party reuse).

In my mind web apps consist of [parts of] pages / templates, menus, forms, and
url structure and underlying models. Django forces me to separate these
concerns. A Good Thing. Then it turns around and forces me to define a group
(app) and lump a bunch of them together again.

~~~
hartror
I disagree. It certainly doesn't force you to do anything. I am working with a
team on a legacy web app we are converting to Django. Because of the legacy
nature we have had to extend and override some of the functionality provided
by Django and have found it an easy and logical process.

And grouping models/forms/views/templates etc certainly has made sense for us
considering the large amount of code we are dealing with. Finding the relevant
section of code is a painless experience.

I do agree with the articles complaint about obscure import errors. My
solution when dealing with that is to drop into the shell and do the import
there to get a better error message. Not ideal but so far it has been the only
pain point we've had to deal with.

~~~
rbanffy
> My solution when dealing with that is to drop into the shell and do the
> import there to get a better error message.

What kind of software developer is afraid to (or don't know how to) do that?

------
jokull
Good call on the apps. I think we can agree the idea of reusable apps hasn't
really worked out. Still, I don't see how this tips anything in favor of
Pylons. As for the debugger, I've been using pdb extensively. Errors thrown by
templates are very annoying however, showing a huge stack trace through the
template rendering scope and nothing to do with whatever caused the error. To
solve this I've had this at the bottom of my urls.py
(<http://dpaste.de/9Emp/>). It prints out exceptions straight to runserver.
Also useful if you're letting project managers test your site and they come
across a bug - you can just inspect it right away.

------
jcapote
Sounds to me that they are just lacking some kind of mountable application
system al a rack?

~~~
didip
In python world, rack is WSGI. Pylons is built around wsgi concept, thus has
access to wsgi apps. I'm not sure how Django handles WSGI entry points. It's
been a while since last time I worked on django app.

See: <http://wsgi.org/wsgi/Middleware_and_Utilities>

------
wakeupthedawn
I agree with his complaints about reusable apps to an extent, but I feel a lot
of the fault has to do with the design of the apps he referred to. I feel that
the good apps are the ones that focus on a very narrow scope and try a
singular problem (Paypal integration, Twitter integration, etc). Pinax tries
to shove every social media idea at you. Other ones like Satchmo (shopping
cart) even have their own templates and styles, sorta like a CRM where you're
kinda meant to use the Admin to manage your shop. I think you can get decent
flexibility with Django as long as you choose simple apps.

I've always liked the Django debugging information and haven't had too many
problems. I agree that it's very possible for many to feel limited by the ORM
and standard templating system.

~~~
megaman821
"I agree that it's very possible for many to feel limited by the ORM and
standard templating system."

For me Django 1.2 is smoothing both of those over. The raw_sql method lets you
construct your own select statements and turns the results into python
objects. Also the if tag is much better. If template tag creation got cleaned
up, I would have almost no problems at all with the template system.

------
swah
When I was deciding for Django, this...

