The mess Django's in

http://mockit.blogspot.com/2010/04/mess-djangos-in.html

by niels • 16 years ago

58 39 16 years ago

mockit.blogspot.com

nudge4• 16 years ago

Not sure I could disagree much more with this. Firstly, I think the power of Django's inbuilt functionality more than makes up for whatever aesthetic problems there might be (I haven't checked) with the underlying code. That's a trade-off I'm very willing to take. Secondly, I'd rather go with messy code and an active bug-fixing and development team than beautiful code that no-one touches. Plus, there's no 'kool aid drinking' going on here. In fact there's surprisingly little razzle-dazzle about Django. All I know is that it helps me build what I want to build, fast, and the documentation is the best I've ever seen for just about anything.

rossj• 16 years ago

It's a blog post on a three year old article - the first comment to the post by Adam starts with the following...

(I'm the author of the 2007 article.) I disagree with you about the Django codebase. Overall, it's well-written, well-tested, and extremely well documented, so much so that I consider it a case study of "what to do with a free software project".

agentultra3• 16 years ago

You have to drink the kool-aid. Django has managed to develop all of its own components. It's not impossible to switch out one of those components for a better one, but you'll be fighting the framework to do it. That's because the Django framework likes to use the Django components. If you don't drink the kool-aid, you're missing the point.

It's a decent framework for what it is and has a large community behind it. Some of the best marketing in a Python project I know about.

Just from memory, the last time I looked at the ORM code it was pretty bad. There were functions that ran on for hundreds of lines without comments or docstrings. Plenty of introspection being used to bypass encapsulation. It wasn't impossible to follow, but it did look a little haphazard and "thrown together" (as opposed to thoughtfully planned out and designed).

SQLAlchemy otoh, is a really good example of well designed and clean code. As far as ORMs and database interfaces go, they have some very clear ideas and concepts they've built up from.

The "mess" I think Django may find itself in is that there are frameworks built on third-party libraries that are easier to use and better to use than Django. Its ORM isn't as great as SQLAlchemy. Its templating engine isn't as great as Mako. For a framework as large as Django I think they will find it harder and harder to keep up with what everyone else is doing as long as they continue to believe that they can "code it all."

nudge4• 16 years ago

Following the conventions of a project in order to take advantage of its strengths is not 'drinking the kool-aid'. If you need custom components and find it hard to integrate them, use something else. Nobody's forcing you to use Django.

Your thoughts about the templating engine vs Mako, and the ORM vs SQLAlchemy are subjective. You should recognize this. I don't mean that one is not better than the other. I just mean that 'better' is really 'better for you and what you want to do'. For me, Django is perfectly sufficient. Similarly subjective is the value you put on 'clean code'. I happen to value a community that tests and makes sure it all works. That is also subjective. Don't confuse your preferences with actual problems with something you are evaluating.

Django works for me, very well. I didn't drink any kool-aid. If it doesn't work for you, that's fine. But if you think the fact that it doesn't work for you, or meet your standards, means that the project is in a mess, then I think you are the one missing the point.

j_baker3• 16 years ago

SQLAlchemy is a great ORM, but I don't think I would say that it's phenomenally better than Django's (at least from a code perspective). Making an ORM have good code is really hard, especially when you support as many databases as SQLAlchemy does. Not only does each database have its own quirks, but their drivers also have their own quirks, and so do the drivers' Python interfaces. And I haven't even gotten into the mess that is dealing with Unicode in Python 2.

Long story short, show me a Python ORM that has clean code, and I'll show you an ORM that either supports just one database or is so buggy as to be unusable.

metamemetics• 16 years ago

You should be able to use SQLAlchemy with your Django database, they aren't mutually exclusive.

Also, if you think you need a more "powerful" template system, you are probably bloating your template with code that should reside in your view functions written in python instead. HTML templates should be mainly HTML.

jiaaro• 16 years ago

I completely agree. I could care less if the underlying code is messy as long as it is actively developed, and works.

The project maintainers on the other hand have an incentive to make the code easy to work on. Especially if they want outside contributers. Not to mention the fact that they themselves (the project maintainers) have to work on it.

_3ex7• 16 years ago

>Even simple things like setting up and tearing down the database is awkward. You have to actually make an outside call to a command-line script to do it.

... Because I want to be able to do that WITHIN my webapp?

As a side note, I wish this guy would of pointed to some specific examples instead of speaking in generalities.

jerguismi• 16 years ago

> As a side note, I wish this guy would of pointed to some specific examples instead of speaking in generalities.

It is very hard to give specific examples, most this kind of blog posts are mostly rants without anything concrete to grasp on. I guess it's mostly about what kind of coding/architectural style are you used to.

For example, I have done rails several years ago. I liked it, but just couple of small projects. Then I started my next site with django, which I liked very much. I found the django's modular system much better than rails, and it was very easy to add functionality through open-source packages and customize them for my needs.

Now I have started contracting project where I fix existing rails project, and it is kind of pain in the ass, because I'm used to django's way of thinking. But I can't give any specific reasons why it sucks, it is just my viewpoint.

digitallogic• 16 years ago

It isn't an issue if all you have is a webapp, but if you plan on interfacing with the database from any other context you're gonna have trouble. Here's an example that should illustrate the point, being unfamiliar with the django code base try to use user input to specify the database credentials.

j_baker3• 16 years ago

I couldn't disagree more that Django's code is horrible. In my experience (which isn't much to be honest), Django's code is a pleasure to read.

That said, I do think that a case can be made that Django's architecture has some definite warts. Whether or not they are a huge deal is largely a matter of opinion. For instance, I do agree with the author that Django does have a bit of an overreliance on import-time side effects. I particularly don't like the fact that I can't even import some parts of Django without having a settings.py defined. On the other hand, I don't know how difficult it would be to change it.

jz• 16 years ago

I've only looked at a small portion of the underlying django code and from what I've seen there were definitely some complicated parts, but it was far from being messy. Perhaps the author is confusing necessary complication with messiness? After all, isn't the purpose of a high level framework to hide the messy details and allow you to express your ideas clearly and efficiently?

I have read and understood all of web.py and am currently buried up to my head in rails actionpack routing code, both contain some hairy bits of code. By pushing all these messy details down into the library they allow the application developer to be more expressive and concise. As long as there are tests, comments, and documentation to back up the complicated bits, I don't have a problem with a library or framework not being obvious to understand at first glance.

c00p3r• 16 years ago

Google uses Django on its AppEngine, at least some parts of it. Seems that it is not so badly written.

barnaby• 16 years ago

Can't say I agree with this either.

angelbob• 16 years ago

It sounds like a lot of the complaints are about their ORM layer. I'll point out that Rails (a very comparable project) has a lot of cruft in ActiveRecord, their ORM layer, as well. I can't directly compare it to Django's, but it's a bit of a hairball. Some of it is just that it's hard to write a good ORM layer.

Let's hope that Django can also take a Rails 3-esque approach -- make the ORM layer modular, then use whichever you like. That's a surprisingly good way to disentangle the internals of the ORM from everything else. And once you do that, it gets a lot easier to polish up the code, or if necessary replace it with something prettier.

I imagine a fair number of the Rails 3 folks will be replacing ActiveRecord with DataMapper, for somewhat similar reasons. I plan to.

Daishiman• 16 years ago

Completely disagree. Most of Django's components are so simple that you can tear them out and replace them for your own thing. I've done it several times now and I never felt confused about it.

ibejoeb• 16 years ago

What? How about an example?

The Django code is concise, readable, and pretty modular. I rarely read the docs anymore; just browse the code. In fact, I feel like a better programmer for having read most of the Django code.

This appears to have been written today, but it reads like it's from 3 years ago.

ubernostrum2• 16 years ago

ORMs are like sausages. You really don't want to know what goes into them.

kingkilr• 16 years ago

Pssh, a lot more love went into the ORM than ever went into a sausage.

ubernostrum2• 16 years ago

You've apparently been eating the wrong kinds of sausages.

kqueue2• 16 years ago

Just because you don't understand the code it doesn't mean it is awful. I am not defending django at all since I use webpy.

Saying the code is awful without proving why is just a way to explain to yourself why you are not understanding the code. It makes you relieved that it is not your fault. However it is your brain deceiving itself.

Blame it on yourself first then on the code.

stevenwei5• 16 years ago

>>> Just because you don't understand the code it doesn't mean it is awful.

Disagree entirely. My philosophy has always been that code is more difficult to maintain than it is to write in the first place, so one of the core tenets of well written code is its simplicity and ease of understanding.

If you write a convoluted mess that's difficult for someone new to pick up right away, it will probably also be difficult for you to jump back into several months later when you need to fix a bug or add features.

Not to mention making it more difficult for third party developers to contribute...

kqueue2• 16 years ago

You are assuming that if you didn't understand the code, then no one can. Hence, if you don't understand it, then it is awful.

What I am saying if you want to say a code is awful, then state why it is awful.

stevenwei5• 16 years ago

I mostly agree with the author of the article: ever try to modify the User object to accept an email instead of username for login purposes? It's a complete hack.

The thing is, it didn't need to be a hack, but some of the core components are really tightly coupled together when they don't need to be, so it ends up being a hack. This tends to happen a lot when you 'go outside the box' of Django's codebase.

For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful.

That said, the alternatives to Django are so incredibly lacking that (for the moment), I'd rather stick with Django than roll my own everything else. Pylons and Turbogears are an ugly mish-mash of third party libraries that don't work well together. In some cases there are good third party libraries (SQLAlchemy is indeed quite an amazing piece of software), but many other pieces are lacking:

  - Authentication/authorization libraries are terrible.
   (You want to bury that in the middleware layer and use
   query string parameters to indicate login failure? What?) 
  - Nothing out there is as good as Django's model forms.
  - There is no equivalent to sorl-thumbnail, for basic image processing.
  - The boatload of third party Django apps. Yes, most
    of these are poorly written and not modular enough either
    but there are some really useful ones out there like django-pagination
    and django-compress.

Django is far from perfect but unfortunately, taken as a whole, it's still better than the current alternatives.

henriklied• 16 years ago

> For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful.

Using SQLAlchemy doesn't change any of that. For pre-built components, like auth and admin, just go with the flow. You're free to use SQLAlchemy side-by-side with Django's ORM.

stevenwei5• 16 years ago

Really? What happens when you want to start customizing the User model, perhaps linking it to a UserProfile. Perhaps you want to have many Users belong to the same Account?

Do you create duplicate representations of your models in SQLAlchemy and Django? What happens when you need to start migrating your database schemas?

Forgive my lack of imagination, but I can't think of any way of doing what you suggest without it coming across like a horrible hack.

zeemonkee3• 16 years ago

I agree with your conclusions on Django auth (and I really hate the UserProfile hack) - and once you start swapping out the template engine and ORM you lose much of the usefulness of Django (as well as most of the 3rd party apps).

If you take away admin, auth etc I really don't see much that's compelling about Django. However you are also correct about Pylons - I would like to recommend it but the documentation is terrible and has its own share of hacks (the "c" global, @validate decorator etc).

Rolling your own isn't that painful though - you might want to look at Werkzeug. Coupled with SQLAlchemy and Jinja2 you have a really nice DIY framework for very little effort, that grows with your project. I'd also like to mention WTForms which uses a similar pattern to Django forms and is very easy to use and extend.

The Flask microframework, while just a few weeks old, is built on top of this toolkit and looks very promising, especially for beginners to Python web development or smaller projects.

stevenwei5• 16 years ago

Yes if I rolled my own it would almost certainly be on top of Werkzeug/SQLAlchemy/Jinja2.

The history of Flask is amusing but I'm not particularly interested in another microframework - 80% of web app development is doing the same boring shit over and over again (user logins, permissions, registration, form processing, image uploads, password resets, REST apis, etc). Microframeworks punt on all of that stuff and expect you to reinvent the wheels there.

We don't need more microframeworks in the Python world, what I really want to see is a full stack alternative to Django that took care of all of the boring stuff so web app developers could focus on the 20% of work that makes their app really unique.

lionshare• 16 years ago

SQL and Objects are a problem in the first place. SQL is optimized when working with sets. So unless simple one-record read/write, most queries should fall to direct SQL which is really easy to do in Django and in Python. And for the one-record transactions, the ORM does not really matter that much. Bottom line: SQL is an essential programming skill.

The mess Django's in

Related Stories