6 ms·

Why I switched to Pylons after using Django for six months

105 points by dryicerx 17y ago

swah 17y ago
When I was deciding for Django, this...
wakeupthedawn 17y ago
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 17y ago
  "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.
matrix 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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 17y ago
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 17y ago
  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 17y ago
    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 ;-)
idan 17y ago
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.
- vanschelven 17y ago
  I'm not too sure models disassemble too gracefully. I can't really take my own app, subclass a model and modify a field, to name just an example.
  - thomaspaine 17y ago
    What? http://docs.djangoproject.com/en/1.1/topics/db/models/#id5 http://docs.djangoproject.com/en/1.1/topics/db/models/#id5
    - enjo 17y ago
      For other cases (Where you don't want to create a new model, just change it's behavior) proxy models are incredibly useful. http://docs.djangoproject.com/en/dev/topics/db/models/#id8 http://docs.djangoproject.com/en/dev/topics/db/models/#id8
- mgrouchy 17y ago
  I think your sentiment here is pretty correct. We have been using Django to build SWIX ( http://www.swixhq.com 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).
vanschelven 17y ago
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 17y ago
  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 17y ago
    > 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 17y ago
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/ 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 17y ago
Sounds to me that they are just lacking some kind of mountable application system al a rack?
- rbanffy 17y ago
  You mean like this http://ericholscher.com/projects/reusable-app-docs/ http://ericholscher.com/projects/reusable-app-docs/ ?
- didip 17y ago
  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 http://wsgi.org/wsgi/Middleware_and_Utilities
theli0nheart 17y ago
The debugger he's so fond of is actually the Paste debugger (paste.exceptions.errormiddleware.ErrorMiddleware). See http://gist.github.com/326254 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 17y ago
  So, how do I build the next Google?

105 points by dryicerx 17y ago

swah 17y ago

When I was deciding for Django, this...

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 17y ago
"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.

matrix 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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 17y ago

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 17y ago
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 17y ago
  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 ;-)

idan 17y ago

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.

vanschelven 17y ago
I'm not too sure models disassemble too gracefully. I can't really take my own app, subclass a model and modify a field, to name just an example.
- thomaspaine 17y ago
  What? http://docs.djangoproject.com/en/1.1/topics/db/models/#id5 http://docs.djangoproject.com/en/1.1/topics/db/models/#id5
  - enjo 17y ago
    For other cases (Where you don't want to create a new model, just change it's behavior) proxy models are incredibly useful. http://docs.djangoproject.com/en/dev/topics/db/models/#id8 http://docs.djangoproject.com/en/dev/topics/db/models/#id8
mgrouchy 17y ago
I think your sentiment here is pretty correct. We have been using Django to build SWIX ( http://www.swixhq.com 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).

vanschelven 17y ago

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 17y ago
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 17y ago
  > 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 17y ago

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/ 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 17y ago

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

rbanffy 17y ago
You mean like this http://ericholscher.com/projects/reusable-app-docs/ http://ericholscher.com/projects/reusable-app-docs/ ?
didip 17y ago
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 http://wsgi.org/wsgi/Middleware_and_Utilities

theli0nheart 17y ago

The debugger he's so fond of is actually the Paste debugger (paste.exceptions.errormiddleware.ErrorMiddleware). See http://gist.github.com/326254 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 17y ago
So, how do I build the next Google?