Hacker News Reader

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.

I should recognize what, exactly? That you're using relativism as a red-herring? I meant what I said, thank you very much.

Not everything is created equal.

SQLAlchemy's ORM is just better than Django's ORM. Better in the majority of objective metrics you can think of. The code is well designed, structured, and documented. It supports better features and more databases. It's not just better because "it works for me."

I didn't say that the Django project itself "is a mess." It still has a great community and leadership. It still has great marketing and strong appeal for a niche audience. What I did say was that Django may find itself in a mess when competing frameworks provide more than Django can offer because they rely on a community of components that individually are better than those offered by Django.

I should mention I base my hypothesis on years of experience developing large and small sites and applications using Django as well as a few years developing websites using other frameworks and using SQLAlchemy.

You're not understanding me.

You say A is better than B, objectively.

I'm telling you that B suffices for my purposes. Given that, the fact that A is objectively better than B doesn't really matter. That fact's importance is subjective. You find it important. I do not.

So you should recognize that what you find as a fault is not necessarily a problem for others, and therefore not necessarily a problem for the project.

By taking the "it works for me" (relativist) position, you're avoiding the central argument.

The OP pointed out that Django's reliance on internal dependencies and import-time side effects is a bad thing.

I agreed and added that the internal components themselves aren't bad, but that it's the superior components that other frameworks are using that makes Django bad.

There are a lot of people out there who could justify using COBOL by your same logic.

I think Mark Ramm was being more prescient than most people give him credit for when he suggested Django could go the way of Zope if it doesn't open up to the wider python eco-system.

The Django ORM isn't the best ORM available and I think it hurts Django to not be able to take advantage of better ORMs without having to sacrifice its core features (admin, authentication, etc).

I'm not avoiding your argument. I'm telling you it's fallacious.

Technologies don't come and go according to whether they're better or worse than other technologies. They really don't. They come and go according to whether enough people decide to use them, or engage with them, or develop them, and so on. If it were as you say then no-one would be using php, which plenty of people would agree is 'worse' than its alternatives.

I mean, you're sort of right. Your argument is just missing a step. It may be that Django's difficulty including other toolkits is a weakness. But that only matters when enough people decide it matters.

You can call that relativism if you like. It doesn't make any difference. But it could just be that Django works fine enough.

Feel free to point out how wrong I am, but if you do it from a qwerty keyboard (an 'objectively' bad keyboard layout), you'll only be proving my point. Problems are only problems when they're problems for people.

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.

I do think you should at least take a look at SQLAlchemy's code before saying it isn't clean. I can tell you that SA's code is exceptionally clean and easy-to-follow (so long as you're comfortable with the 'a-class-for-everything' way of working, which is what makes sense in their case).

As for messy code in Django, well that really isn't that fair. Sure, some of the things they do with imports is, frankly, scary, but there are very few cases where this becomes a problem, and when it does, there is always a workaround. Where, in my opinion, Django's ORM falls short is it doesn't really like you to think you're interacting with a database… many things that would be very useful just aren't there (swapping out ORM-generated SQL with a hand-written counterpart, for instance, is next to impossible). The typical solution to this seems to be "well, you can get a database cursor and do as you please"… but there comes a point where this just isn't good enough.

However, if Django's ORM just can't cut it for you on a project for whatever reason, it really isn't that hard to ditch and switch to something else (like SA). Yes, you will lose the admin, and you'll lose the authentication and session components (though these are actually easier than one might assume to get working under another ORM with their 'backends' concept), but you still have an amazing framework without these components.

Reading this article seems, to me, like the guy has taken one brief look at Django's internals before going on to condemn them as ugly in this post. And that's really not cool.

I have looked at SQLAlchemy's code, and I think it's about as clean as can be expected for an ORM. I wasn't trying to put SQLAlchemy down. I'm just saying that you have to apply a bit lower standard for ORM code than you would other parts of the code.

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.