3 ms·

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

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."

nudge 17y 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.
- agentultra 17y ago
  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.
  - nudge 17y ago
    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.
    - agentultra 17y ago
      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).
j_baker 17y 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.
- obeattie 17y ago
  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.
  - j_baker 17y ago
    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.
metamemetics 17y 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.

nudge 17y 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.

agentultra 17y ago
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.
- nudge 17y ago
  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.
  - agentultra 17y ago
    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).

j_baker 17y 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.

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

metamemetics 17y 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.