Why I switched to Pylons after using Django for six months


I started using Django in June for a side project. A friend told me about it, he wanted to use it for a project we were going to do and it seemed great. Unfortunately, none of those projects went live (for non-technical reasons). A few months later, I am helping another friend with django-based website, and I also redid my personal website in django (albeit a very peculiar use of django) and I have other plans for django websites based on the framework I built for myself.

Two months ago, I decided to rewrite a website I manage (PAPS) in django. It was drupal-based, which had served us well, but it was, by now too old and inflexible. One of the things that disturbed me about it was that I had started tweaking the code. Not much, but enough that I was afraid to upgrade and lose those changes.

Also, I wanted recaptcha on signups, openid logins, twitter integration and a bit of a feeling of modernity. I worked on it a few hours per week, in the evenings, but I didn’t make much progress until I switched to Pylons. By then, I had invested a month into the project, but kept getting stuck and moving forward only at immense effort.


First, the good: its documentation is deservedly regarded as impeccable and an example to us all. Its really easy to set up a very simple website and have it just work fast.

Now, the bad: One of the major reasons why I thought that django was so great was the vibrant community of people writing apps. However, I think that this also exposes django’s basic architectural flaw: the app system is not the right system to break up functionality. This is why there is so much talk of reusable apps: most existing ones are hard to reuse.

I first tried pinax or one of the content management systems. As usual, you get a working website instantly, but then you hit a productivity barrier very fast. Then, I tried a bunch of apps to get the pieces of functionality I wanted and get them to play together. What I wanted to avoid was to fork the code and
adapt it to my project. Then, I would be forced to maintain it and diverging from the main tree.

I tried. I really did. But I could never really get open id to work. I gave up on almost all of the apps I tried too. They would have a structure that didn’t fit into the rest of my application, I would need to tweak the templates (most by reading the code to see what was going on, which names it exported). I would need to fix the urls and url names. I would basically be forking each app to work with my desires instead of re-using it.

Fundamentally, the app model is the wrong abstraction for reuse in web-applications. I don’t have an answer, but I know that the app model does not work. How does, say, recaptcha authentication fit into the app model? What are its models, its views, its templates? It’s better handled as a different sort of reuse. What if I want to have a photo gallery and have the insertion of new photos trigger a tweet? I always end up taking someone’s code and modifying when what I wanted was to take someone’s code and call it.

What finally broke the camels back was when I was working with a django model and thought Sqlalchemy would be so much better. So, I decided to try Pylons.

Later that evening, I had ported almost all my existing work to Pylons. The next day, I had made progress. Also, I finally stopped feeling frustrated.


Pylons seems to get a bit less attention. The reasoning seems to be: django is better for simple sites, Pylons for complex sites. Most sites are simple. Therefore, django is more popular.

What I finally figured is that, if you’re writing most of the code yourself or editing other people’s stuff so badly that you might as well start from a couple of snippets, what is django buying you?

I can use sqlalchemy and I can use mako as a templating engine. I never really liked django’s ORM nor its templating engine. I know you can change the template language, but then other apps get very unhappy. Use best of breed for your tools instead of not-invented here is a good principle.

The debugger that comes with Pylons is awesome: if there is an error in your code, you can actually get an HTML+Ajax python shell on the webpage where you can inspect the state of the programme. SQLAlchemy’s error messages are beautiful. Here’s a recent one (from FormAlchemy): No session found. Either bind a session explicitly, or specify relation options manually so FormAlchemy doesn’t try to autoload them.

Here’s a screenshot of the debugger.

Pylons Error

The contrast with django is immense. After months of daily use, I still feel stumped trying to decipher its error messages. Not always, but enough times that its frustrating. Just yesterday, another friend called me up on a Django problem. manage.py was not finding settings.py anymore because django plays around with the paths and the imports in a weird way and there was an impossible to understand relationships to recent changes because it worked in previous versions.

There is nothing wrong with magic in a system (rarely do you hear someone complain that their framework is too magical for working with files, just let me see the disk sectors). But unfinished magic is very frustrating. Unfinished magic most often manifests when the error messages are not magical. So, it just works or it just doesn’t work. As if your operating system spat out a bunch of references to virtual file systems and inodes when you mistyped a file name instead of saying File mixpelled.txt not found. Django has too much unfinished magic: if you make a little typo, then you get an obscure error in a place unrelated to your typo. SQLAlchemy is finished magic: half the time it even suggests a solution to
your problem.

Then there are the little irritations in django: the Sites app is obviously something that solved a problem in django’s original environment, but is a nuisance for the other 99% of cases. The fact that the username cannot be an email: Such a limitation is out of place in a general purpose framework.

I do miss the admin interface.


Django is good if your website is simple and Pylons is better if it is complex. I still agree with this statement, but I have lowered the bar for simple dramatically to mean “almost static” webpages. Pylons has a slightly higher learning curve and takes a bit of time to get to something that works well, but, if you know django, you can start writing code very very fast because most of the concepts are so similar.

The debugger on Pylons is so nice it makes it worth the switch.

Right now, unless my site was braindead simple, I would never go back to Django.

Follow me on twitter: @luispedrocoelho



#1 Shannon on 03.08.10 at 7:48 am

This seems to echo my experience of Joomla vs Drupal, the former being comparable to Django. It was fairly simple to get up and running, but outside of very simple modifications everything started breaking. The dependencies of the various plugins/modules/components (even the nomenclature was obfuscated) were fragile as glass. Drupal had a robust core that didn’t do a whole lot to start but was infinitely extensible.

Waldo probably won’t get complex enough over the rest of the semester to warrant a switch to Pylons, but it’s definitely something to keep in mind.

#2 Jonathan Ellis on 03.08.10 at 12:50 pm

Have you tried the FormAlchemy admin?

#3 masklinn on 03.08.10 at 2:12 pm

> I do miss the admin interface.

You could always use introspection to generate Django models from your database and setup a django site containing just the admin.

#4 tocapa on 03.08.10 at 2:19 pm

While I fell in love with Django at first sight, it is currently becoming a big hassle in my current project because of the lack of flexibility I’m finding. I haven’t looked at Pylons but I’m definitely starting to think about other directions.

#5 James Casbon on 03.08.10 at 3:07 pm

Use werkzeug debugger with django:

#6 Steven Wei on 03.08.10 at 3:42 pm

I agree with you, the entire app model for plugins just doesn’t work well, and unfortunately a lot of the apps are of somewhat poor quality, written for someone else’s project and thrown over the wall.

Using a third party app for basic functionality shouldn’t force a url structure and model structure on your project. Especially if each app has to live independently, creating its own database tables and awkward joins just to add some feature to an existing model.

#7 zap on 03.08.10 at 4:16 pm

Perhaps you shouldn’t try to use Django as an app/cms engine, but rather as a mvc framework. It’s defenitely suitable for complex applications. Write your own code using the framework instead of reusing third party apps. In power it’s comparable to for instance Spring for Java or any other mvc solution.

#8 Anthony on 03.08.10 at 4:32 pm

Interestingly, I just switched from Pylons to Django for a work project, for pretty much exactly the same reasons that you describe – 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).

So far I haven’t run into any lack of flexibility, and I’ve been using Django for fairly serious stuff (mainly as a general-purpose CMS, heavy admin screen work)

#9 Oinopion on 03.08.10 at 4:43 pm

There’s bazilion web frameworks out there and there will always be one, that would fix your current problem right away. Unfortunately, it’s not one you’re using.

#10 Why I switched to Pylons after using Django for six months on 03.08.10 at 4:59 pm

[…] full post on Hacker News If you enjoyed this article, please consider sharing it! Tagged with: after • […]

#11 Matt Doar on 03.08.10 at 5:04 pm

I looked at both of these a year ago and chose Pylons to write a web app. It was easy enough, gave me a good feeling in the docs, and the debugger is indeed excellent. Most of my hard work came from not grokking the depths of SQLAlchemy at the start. I recommend Pylons to people wanting to go down this path: it’s just not that hard.

#12 jaymz on 03.08.10 at 5:13 pm

I can understand where you’re coming from with regards “reusable” apps. It is tricky to get lots of the apps out there to play nice but I’m still completely in love with django. A big part of it is having that out-of-the-box admin ready to go. We use it as our framework of choice internally so a lot of the hassle we had at the beginning with apps has gone away as we’ve built up a core base of code.

In any case, django or pylons+… its good to be coding for the web in python :)

#13 Tony Landis on 03.08.10 at 5:45 pm

Thank for the article, I had similar experiences with Django and Pylons.

#14 Executor on 03.08.10 at 5:59 pm

You probably wouldn’t have had so many problems with Pylons if you had just constructed additional ones.

#15 Areth on 03.08.10 at 7:48 pm

This article should be re-titled to “It took me 6 months to realize Django is not a swill infused CMS like Drupal.” In all seriousness this post was short on facts or thoughtful critique and big on FUD and relatively uninformed personal opinion. As far as I can tell your main gripe is that there wasn’t enough “free stuff” available for Django…that’s weak platform for dumping and MVC framework.

#16 Antoine Leclair on 03.08.10 at 8:39 pm

I used Pylons for a project with MongoDB. I was (and still am) really impressed by this framework. Then, for another project, I had to use Django for its Geodjango framework (I wasn’t aware of the existence of GeoAlchemy at that time).

Django first impressed me (the admin, the reusable apps), but soon after I started, I realized the time I won at the begining was insignificant compared to the time lost when I had to customize things, write template tags, connect apps with signals.

The django templates are weak (only since 1.2 you can do “if my_var > 1″… comon) and django in general is hard to debbug.

Even though I still think Django is best suited to build CMS for simple sites, I’ll definitely have a look at FormAlchemy.

#17 Hang on 03.08.10 at 10:17 pm

Not that I disagree with your conclusion but your article just wasn’t very convincing at all. As far as I can tell, you chose Pylons over Django because Pylons suited your needs and preferences better. However, as a reader, you did not convince me why Pylons is generally better or more preferable than Django. I’m not convinced one way or another. The most convincing argument you gave was the debugger when Pylons throws an error. That’s definitely something Django lacks and something most people would regard as a plus. However, your argument “Sqlalchemy would be so much better” is just begging the question. It boils down, “I want to use Pylons because I want to use Pylons.” There are bits and pieces of reasons why Pylons is better than Django but the assertion that “Django for simple sites; Pylons for complex sites” is not well supported by what’s laid in the article. From my own experience with Django, it works quite well for complex sites (although the meaning of complex is debatable).

#18 Vincent on 03.09.10 at 12:37 am


Your analysis is really quite amateur. Why does he have to convince anyone? Does it really matter which is better? I thought he was being very kind to Django, and provided very good reasons why he made the switch.

The “stop criticizing Django ’cause it works, and I love it” attitude only identifies you as someone who can’t have an objective discussion about the facts.

If you have not yet had the experience of manually dropping into SQL to perform a query that the Django ORM couldn’t handle your site probably wasn’t complex enough to stretch beyond the limits of Django. Ever tried modifying the auth system in Django to use only email addresses, or open id? These are things that most certainly stretch the boundaries of Django. And don’t get me started on the templating system, which has good ideas but is very crippled for anything but simple logic.

I really like Django, I use it daily in multiple very complex projects. When you really get to know Django, you will learn the limits of the framework, and how sometimes your hands are tied, and you would have to modify the django library itself to accomplish what you need. There is a tradeoff, it’s either easy now or later. Django is easy now, harder later(probably much later, but maybe sooner than you’d like). Pylons is hard now, but easy later(probably much later, but maybe sooner).

#19 Armin Ronacher on 03.09.10 at 1:52 am

As much as I would love to see Jinja being part of Django and some other components being replaced by more powerful libraries (thinkingvof the ORM and the URL matching here) I think Django is on the right track.

The reusable app problem you are talking about is unsolved on Python web frameworks in generals, mainly because it is not a simple problem. I think Zope sortof has a solution for that problem. I am not sure about that, because what always kspt me from seriously trying Zope is the high complexity in the system. If we try to make everything reusable with plugable template engines, orms, javascript frameworks, partial templates creating one page under a common layout we probably end up with a system of the same complexity JEE has.

I am not saying pylons might not be a better choice for you, most likely it is, especially because you like it more. But: do not expect salvation by moving to new lands. The reason django js so popular and easy to approach is also what makes it inflexible. You *can* swap out the template engine, it is just not a core feature and youbwill end up replicating things already implemented.

#20 Aurélien on 03.09.10 at 6:29 am

The reusable app is unachievable because apps are coarse-grained things. Little details make sense as part of the finished, delivered product that is an app. An app is by definition a cohesive bulky whole.

OTOH a component system is what frameworks should provide and where reusability has to be done. An app could be made of tens of reusable, properly customized, adapted components. It is perfectly doable and already done :)

#21 Jens Hoffrichter on 03.09.10 at 6:59 am

The plugin thing seems to be a rather big problem, in general, especially if you try to plugin different templating systems.

I’ve been developing with Pylons for quite some time now (2 years+), and I have seen some rather hard changes in it, like the dropping of Buffet a year ago (which didn’t hit me at all, as we were just using Mako templates), or the dropping of rails-style helpers (which still is kinda deal-breaking for us – we didn’t have the heart yet to upgrade to a version past

But compared to other MVC solutions, Pylons is still one of the best choices out there, IMO, and I tried quite a bit of them.

As soon as I try to use something in PHP, I always end up really soon with, “Ugh, PHP is still so ugly”, and don’t get me started on Java frameworks – though Grails isn’t too bad ;)

But the one thing which is pointed out here, and I have yet to seen integrated in another framework, is the debugger. It is SO powerful, and cuts down on so much of your debugging time. And you really start to appreciate SQLAlchemy when you start doing joins over 8 and more tables, and it is still simple to query for the information you need.

I haven’t looked yet at FormAlchemy, but we are planning on doing so for the next project….

#22 Hang on 03.09.10 at 7:26 am


My comment merely refers to quality of the article he has written. Notice that I didn’t dispute any of the points he has made nor did I say Django is good or better than Pylons. All I am saying is that this article isn’t well written.

As for your comment, “Why does he have to convince anyone? Does it really matter which is better?” Of course it does if I assume that the author wants to do something valuable and useful for his readers. Why would he write something that leaves his readers no more knowledgeable or enlightened than before they read his article? I know this is the Internet and there is a lot of useless material out there. I’m giving the author the benefit of the doubt and assuming he’s a smart person with good intentions.

You make too many assumptions about me based on my comment. I said almost nothing technical that would lead you to assume that I have never reached the limits of Django. Yes, I have hit some of its limits. The authentication system was definitely one of them. The SQL/ORM limits I have not hit.

Either way, that’s relevant to this discussion because I’m not saying Django is better than Pylons, etc. In fact, I’m not making claims about either. However, as someone who wants to learn more about how the two compare, this article doesn’t do very much. The article talked about a few points of difficulty in Django but doesn’t really go into detail about how bad it is in Django and why it is better in Pylons. There are more conclusions than supporting details. For example, “I can use sqlalchemy and I can use mako as a templating engine. I never really liked django’s ORM nor its templating engine. I know you can change the template language” Why doesn’t he like the ORM or templating engine? How is this better in Pylons?

Again, I’m not saying one is better than the other but a number of claims are made in this article and the article would be better if the author could expand on those. I’m leaving feedback as a reader who wants to know more about the subject and hoping the feedback would help the author make the article better.

#23 Adam Nelson on 03.09.10 at 7:42 am

Just to move this discussion into the real world, these are the external apps I use (in addition to werkzeug):


There are many missing apps in the Django universe, like a strong alerts system. We’ve rolled our own alerts system which we hope to open source soon. While our alert system uses Django elements, most of the issues are pure-Python, metaclasses, etc… There’s plenty of power in Python itself of course.

Are people saying that Pylons helps users in the situations where a Django user would have had to dip into pure Python?

#24 Justin Lilly on 03.09.10 at 8:05 am

The basic idea here is that you didn’t know what you were doing, so you dislike django.

From the article:

> I gave up on almost all of the apps I tried too. They
> would have a structure that didn’t fit into the rest of my
> application, I would need to tweak the templates
> (most by reading the code to see what was going on,
> which names it exported). I would need to fix the urls
> and url names. I would basically be forking each app to
> work with my desires instead of re-using it.

You can define templates and your own urls without “forking” a project. Django has specific hooks for this.

Regarding his quip about recaptcha authentication, its possible that recaptcha doesn’t belong in an “app”. Perhaps its a plugin to an existing app (for instance, django-registration). That said, csrf implements vaguely the same thing as recaptcha (put something in a form, then validate it) and its implemented as a contrib module (ie: reusable app), so its not impossible to do it that way either.

> It’s better handled as a different sort of reuse. What if
> I want to have a photo gallery and have the insertion
> of new photos trigger a tweet?

This is where signals come in. You can have your twitter app (or any other app) fire off a tweet when a photo is created. I’m thinking this is on the order of 5 lines of code.

Most of the points in the article just boil down to “I prefer the things that Pylons offer, therefor Django is bad.”, which is bullshit.

#25 Eric on 03.09.10 at 11:56 am

It find it very confusing when you say simple site and complex site. How is that measured? I don’t want to be a wiseass or anything, but would you go into detail as to how you measure that? Thanks!

#26 » links for 2010-03-09 (Dhananjay Nene) on 03.09.10 at 1:02 pm

[…] Why I switched to Pylons after using Django for six months — Mutual Information Why I switched to Pylons after using Django for six months http://is.gd/a2qFY (tags: via:packrati.us) […]

#27 FC on 03.09.10 at 4:23 pm

I say give a look into web2py. It deserves at least a look.

#28 For Some Definition of “Reusable” – yergler.net on 03.09.10 at 7:38 pm

[…] read “Why I switched to Pylons after using Django for six months” yesterday, and it mirrors something I’ve been thinking about off and on for the past year or […]

#29 Rohit on 03.09.10 at 11:40 pm

Interesting post. I’ve been trying to make a decision which framework to choose for a project. I need to make a webmail application and I would assume that it comes under the complex category. So do you think Pylons is a better choice than Django ? I guess its possible to do it in Django as well but I don’t want to spend a lot of time arm twisting it to make it work the way I want it to.

#30 Łukasz Korzybski on 03.10.10 at 6:03 am

When you use some gallery application and you need to send twitter update on photo insertion, you shouldn’t modify the gallery application. Just much much better solution is to use signals (events). Create some module in your app that will glue gallery app with your functionality using django signals, and you’re done.

Events are almost always better imho to glue reused apps than putting the custom functionality into one of the apps involved in the interaction.

#31 Naos on 03.10.10 at 6:21 am

sklep.optionall.pl is a 100% Django app, online payments, carts, orders, full text search, etc, not so simple.

#32 Brandon on 03.10.10 at 11:41 am

Django is better for simple sites? How so? I’ve built some very complicated things in Django. We built the Texas Tribune in 4 weeks with Django, and it is not a simple system. Admin alone saved us weeks, if not months of development time, which you won’t get with Pylons.

I think both Django and Pylons are great frameworks, but your inability to make something happen in a particular framework because you didn’t read the documentation is not a shortcoming of the framework.

#33 Omar Gomez on 03.10.10 at 5:47 pm

Never been a Django user, but I think Pylons achieves at having a great balance between flexibility and complexity. At first sight Django appears to sacrifice the former for the later.

#34 Random Links #152 | YASDW - yet another software developer weblog on 03.15.10 at 11:57 am

[…] Why I switched to Pylons after using Django for six months Django vs. Pylons […]

#35 ksamuel on 03.22.10 at 3:27 am

The real trouble is that django, because is so simple, let beginers in the illusion that everything is simple. Reusable app is not simple, and that’s why most of the dev get it wrong.

The app paradigm is not the problem, maybe the name is misleading, but you can do exactly the same thing than with a plugin or such, providing you know what you are doing.

This is true that because Django makes a lot of magic, most dev don’t know what’s really happening. The trouble is that they don’t try to know, while in Pylons you are forced to.

But if you really know how stuff works, then you can do anything : it’s just Python.

I agree that SQLAchemy is so much better than the Django ORM, but it’s good enough, let you generate forms and the admin. It’s worth it.

Eventually, all the nice debugging features of Pylons can be obtained using, you guess it, apps ! For an ajax debugger, install werkzeug and django-extensions, and you are done.

Django is good for complex website too. It just implies to do the work you’ve done when learning Pylons far later in the learning process. When you think you have mastered Django, it’s time to understand how it works and how you can tweak it. And then, there is no limit.

Django is simple for the simple cases.
Django is complex for the complex cases.

Just like Python is, if you think about it.

#36 There’s nothing wrong with apps on 04.11.10 at 5:55 am

[…] random chatter lately about the trouble with reusable apps in Django, succinctly epitomized by this remark from Luís Pedro Coelho: “the app system is not the right system to break up […]

#37 Peter on 04.26.10 at 1:51 pm

I hear where you’re coming from. I’ve been using Django for almost a year now and produced two substantial apps in it.

Overall I’m happy with Django, but my #1 gripe is how tightly the user model is integrated with the framework, and how inflexible this is.

This is a part of the Django learning curve that just doesn’t seem to go away: I now have to start work on an app that must support multiple authentication backends (including even some that _gasp_ don’t use passwords and/or have their own additional UI), multiple “user profiles” and multi-tenant (ie, “sites”) — and the way these concepts are abstracted in Django makes me want to cry. I dread having to hack Django to the point where it will work for me, not against me.

OTOH, given my investment in Django, switching over to Pylons feels like major surgery. For instance, I’ve finally gotten the forms thing working the way I want (also an API with a lot of stuff below-the-waterline…), and I don’t exactly relish reinventing this from scratch on Pylons… But I guess I will take another look at Pylons before continuing with Django.

#38 Michael Short on 05.02.10 at 8:40 am

I originally started a project of mine in Django only to find out that the ORM couldn’t handle the types of queries that I needed to perform. Not only that, but the ORM in Django forces it’s own database conventions on developers. I realize that you can hack SQLAlchemy into Django, but after testing Pylons it was clear that I needed to rewrite my application in Pylons.

Django gets far too much praise compared to Pylons IMHO. The ORM wasn’t the extent of my problems either. Deploying my project with Django was an absolute nightmare.

#39 Bob S. on 06.27.10 at 8:30 pm

I am inexperienced in all of Python, Django, and Pylon. I’ve spent too much time with Joomla and found that there were too many instances where I was hacking away at something that had lines and lines of PHP code that I did not understand.

I spent years working as a C programmer working directly with Unix source code so I am very experienced at programming. I am looking for something that can either let me work at a very low level on a few select problems but on a very high level for most things,

I’m still looking.

What about Web2py?

#40 Chapagain, Anish on 09.16.10 at 1:45 pm

thank’s for sharing such a great experience, and am now getting divert to Pylon to try for the greatness in programming effort by own initiative.

#41 Michael on 09.17.10 at 11:25 pm

This article has given me hope. As a few folks mentioned, the article isn’t very enlightening, but the idea it brings up, and the number of comments it has received tell me that there actually might be more out there than just Django. I love Django for a number of its ways and conventions, but I’ve reached (slammed into) the ceiling many times in my current software project. I’ll tell you what I have now; I no longer use auth, sites or admin. They’re not even in INSTALLED_APPS. I wrote my own auth system which works well in my multitenant architecture. My project is a SAAS so admin won’t help me. I use django only for the ORM, sessions, messages, model forms, templates, and request handling in general. I’ve been slowly realizing that django is just a few guys’ tool that they use for their own business and decided that open source was a good idea. It’s basically a glorified CRUD interface to a news website. It has a lot of cool features, but lacks a little in the general purpose enterprise MVC arena.

#42 кран балка on 01.28.11 at 11:34 pm

Great info dude!!

#43 Roman on 02.04.11 at 3:23 am

Thanks for the article!
I just curios, what can you guys tell about Ruby on Rails compared to django/pylons etc. for complex sites?

#44 Andy on 02.07.11 at 1:26 pm

Thanks for the article and all the comments, maybe I should use Pylons for my project.

#45 Paulo Santos on 03.15.11 at 4:34 pm

I always have problems with Django. I only used it because Guido says good things in a post, it was a disappointment.

#46 Rei Ayanami on 04.13.11 at 8:49 am

Well, Django has a debugger interface, too (as a separate app though).

On ORM… Well, maybe so. In fact, I’m working on quite a number of Django-based projects, and very rarely there is need for something really fancy and/or sophisticated in this field (and high performance is achieved mostly with bare SQL, anyway).

Nice post.

#47 Thomas Güttler on 07.06.11 at 3:42 am

Can you explain why SQLAlchemy should be better than the ORM of Django? I like the django ORM very much. The lookup of foreignkeys with two underscores is great.

I use two external APPS: south and reversion. But you are right: There are many buggy and unsupported django APPs.

#48 Izz ad-Din Ruhulessin on 07.17.11 at 4:12 am

I think it should be pointed out that you do not *have* to use django.contrib.auth or django.contrib.admin. They are in the ‘contrib’ directory for a reason. And even the Django manual states that it is perfectly possible to write your own authentication or admin backend if you do not like the one that comes out of the box.

The power of Django is that you do not have to use anything that it offers. If you do not like the templating system, you can write your own or use a third-party. If you do not like the way request objects function, you can alter them using middleware or even completely implement your own. If you do not like the ORM, you can make raw queries. You can, with some skill, even combine Django with non-Python web applications like Drupal or PHP.

As for the criticizem on the app system, I think people should understand that bad reusability is not a flaw of this app system, but a flaw of the app design. Abstracting software to a level that it becomes reusable is a skill in itself, and not every programmer posseses this skill.

#49 Izz ad-Din Ruhulessin on 07.17.11 at 4:13 am

Where I wrote PHP I ment ‘Joomla’

#50 Roberto Rosario on 12.04.11 at 12:15 pm

“django is better for simple sites…” Yeah, that’s why I chose it to build a 13K lines web based document management system

#51 Karen Davis on 12.14.11 at 5:07 am


#52 Ravi on 02.06.12 at 12:38 pm

This seems like Django did something with you :). I been using Django for quite 2 years, and I know where is lacks and their workarounds. In querying, sometimes I have to get off the ORM and start using plain sql. But most of time I take Django as MVC and laid standard framework for my app.
Adding EMail as username (or login with anyone) is quite a 30 mins of work (but it won’t let you use loggig in admin with email though).

#53 Django vs Pylons | blog.arah.at on 08.15.12 at 8:46 am

[…] Cual usar? dependerá ahora de los requerimientos que tengan.. yo en particular uso ambos, pues resuelven adecuadamente distintos problemas. así que según sea el caso, uso uno u otro. Para más información les dejaré estos links para el debate. http://stackoverflow.com/questions/48681/pros-cons-of-django-vs-pylonshttp://stackoverflow.com/questions/1344824/django-vs-pylonshttp://www.noise-media.com/blog/pylons-vs-django/http://www.mutualinformation.org/2010/03/why-i-switched-to-pylons-after-using-django-for-six-months/http://jordanovski.com/django-vs-pylons Anímense a probar ambos Frameworks, realmente son excelentes herramientas. Esta entrada fue publicada en comparación, django, frameworks, opinión, pylons, web por arahat. Guarda el enlace permanente. […]

#54 Django vs Pylons | blog.arah.at on 08.15.12 at 9:24 am

[…] Cual usar? dependerá ahora de los requerimientos que tengan.. yo en particular uso ambos, pues resuelven adecuadamente distintos problemas. así que según sea el caso, uso uno u otro. Para más información les dejaré estos links para el debate. http://stackoverflow.com/questions/48681/pros-cons-of-django-vs-pylonshttp://stackoverflow.com/questions/1344824/django-vs-pylonshttp://www.noise-media.com/blog/pylons-vs-django/http://www.mutualinformation.org/2010/03/why-i-switched-to-pylons-after-using-django-for-six-months/http://jordanovski.com/django-vs-pylons Anímense a probar ambos Frameworks, realmente son excelentes herramientas. Esta entrada fue publicada en comparación técnica, django, frameworks, opinión, técnico por arahat. Guarda el enlace permanente. […]

#55 Django vs Pylons | atmantree.com on 10.04.12 at 7:13 pm

[…] http://www.noise-media.com/blog/pylons-vs-django/ http://www.mutualinformation.org/2010/03/why-i-switched-to-pylons-after-using-django-for-six-months/ http://jordanovski.com/django-vs-pylons Anímense a probar ambos Frameworks, realmente son […]

#56 Craig on 11.06.12 at 8:09 am

Coming from someone who uses Django every day and loves it, and has never used Pylons (but is interested because it is Python, if nothing else), I will add this:

Django is good for data-driven sites. If you need high user interactivity and constantly changing things, Django really shines. I truly believe this.

I would never, and I repeat never, use it for a CMS. I can’t say whether or not Pylons would stand in for that role or not, but honestly I might just drop all the way back to WordPress for a project like that.

To me, it comes down to data-driven projects vs. content-driven projects. For data-driven, Django has yet to disappoint.

#57 James Lin on 03.18.13 at 12:59 am

For Django 1.5, you can use your custom User models, for using different authentication methods, have you guys looked at writing your auth backends? It’s not that hard, we changed it to use ldap, then email, then username as fallback.

Please define complex, to me, complex can mean a lot of apps and models, business rules require a number of pages/steps to complete, or even complex algorithms and calculations. And I don’t see why django will not suit any of these complex situations.

#58 Thurman Woods on 04.09.13 at 8:48 pm

Keep to concentrate your point, this is nice blog.

#59 Toney Volmer on 04.30.13 at 9:37 am

Urgent!!! I just came across your Blog and was shocked to find out that your WordPress Installation is unprotected from attacks against hackers. There are currently a lot of brute force attacks against WordPress Installations but there is an easy fix. You just have to install one of these Security Plugins that makes it really hard to breach into your website, if you are interested check this post out –> http://bit.ly/11si4le All the best, Toney Volmer

#60 pistol targets showing human vitals on 05.12.13 at 4:56 am

Thank you a lot for sharing this with all folks you actually know what
you’re talking approximately! Bookmarked. Kindly also visit my web site =). We can have a link alternate agreement among us

#61 Cj Welborn on 06.03.13 at 11:45 am

I currently use Django on my site, and I really like it.

There are a few things I’ve noticed, like multiple-domains, ajax debugging, and easy model-updates, but I think I agree with a few of these other posters. These problems can be solved by writing your own stuff. I looked at the third-party apps, and I think you’re right to say that they were designed for someone else’s site and “thrown over the wall”, or maybe they were designed for a very basic, by-the-book, site.

I took a look at some of the blog & search apps when I first started and said “no thank you, I’ll write my own”. I’m glad I did because now I know every line code that made it happen, and exactly where to go if I need to extend something. What I’m doing wouldn’t be considered ‘complex’ by professional programming standards, but I’m pretty sure there is no app that would fit in with my current models and templates. It just wouldn’t be what I want it to be.

I’ve never used Pylons. I actually used Joomla before I figured out how much I hate it (i’m just not into PHP). I was able to take all of my Joomla functionality and transfer it to Django plus a lot of other features that I (personally) would not have been able to do before. The admin is different, but I’m tweaking that too.

Long story short, I’m a huge python/django fan. I’ve hit a small limit here and there but I’ve always been able to work at it and get what I want. The possibilities are endless. I’ll be sure to check out Pylons, I’m all about learning something new (to me).

#62 Tassadar on 07.08.13 at 6:54 am

@14: En Taro Executor! ;-)

#63 Prices buy cialis cialas on 08.24.13 at 9:19 pm

cthwgnvuvbmjogpsnbujpo, Safe sites to buy cialis, boAxMDX, [url=http://www.northplains.org/index.php/about-north-plains]Buy cialis specialized cialis online pharmacy[/url], XQgYJfY, http://www.northplains.org/index.php/about-north-plains Buy cialis softtabs online, fKFGiyo.

#64 site on 10.18.13 at 3:37 am

I do trust all of the ideas you’ve presented to your post.

They are very convincing and can definitely work. Nonetheless, the posts are very brief for novices.

May just you please prolong them a bit from subsequent time?
Thank you for the post.

#65 outletzueyx on 11.28.13 at 12:20 am

christian louboutin uk .gPsp ҐЗҐеҐЩҐЖҐЈҐ« ҐЗҐЈҐЄҐЛҐ·ҐЄ DZSrb billige parajumpers v:>R/ parajumpers jakke oslo fA(PC ҐЗҐеҐЩҐЖҐЈҐ« ҐЗҐЈҐЄҐЛҐ·ҐЄ pMX – g

#66 rekSterse on 11.28.13 at 12:20 am

これは、プラダのメガネ融合にする傾向が、驚くほど強力な供給のためにこれらの3の個別のコンポーネントを使用して再接続します chanluu 芸能人
:本当に安いかどうか? 価格比較のための究極のリファレンス チャンルー ラップブレス
私たちの一部は、30年のレトロであった、Bobbitoが言うには、今、私たちは、人々があってもボールをプレーしていないジャージを着て持っている chanluu 松潤
Samajwadi党首ジャヤプラダジッパーバッチャンは金曜日にプラダジッパーはマハラシュトラ州政治の論争の引き金となってきましたBandraWorliシーリンクの就任式に出席するために謝罪する彼女の夫アミターブ·バッチャンの必要はありませんでしたと述べた チャンルー 取り扱い店舗

#67 fred on 12.28.13 at 10:05 am

And now that Pylons has been dead ended with no easy upgrade to Pyramid I wonder how wise you now think this decision was.

#68 outletctpin on 01.02.14 at 10:59 pm

michael kors handbags outlet fJgbl ҐЗҐеҐЩҐЖҐЈҐ« ҐмҐЗҐЈ©`Ґ№ riYbE [url=http://www.vtdotnet.org/menu.asp]ҐўҐ°ҐЄ©`Ґ№ҐИҐйҐкҐў[/url] c`Ft] [url=http://www.loayoman.com/defaultold.asp]tiffany outlet[/url] w\]0Z ҐЗҐеҐЩҐЖҐЈҐ« ҐАҐ¦Ґу S:I’O

#69 outletwoghk on 02.09.14 at 3:03 pm

ammuniton moderations disowne http://www.cabotbaseball.com usum lichanov mopitt

#70 rousse on 05.22.14 at 7:45 am

Je comptais justement rédiger un petit poste pareil
à celui là

#71 Cheap Viagra on 06.15.14 at 3:53 pm

At the end…

i always syndicate…

Leave a Comment