5 ms·

The issue that I have with that attitude (as an experienced Python and Django developer) is that there's a lot more to it than just "swapping out Django's DB an

The issue that I have with that attitude (as an experienced Python and Django developer) is that there's a lot more to it than just "swapping out Django's DB and replacing it with SQLAlchemy". You miss out on most of the infrastructure around Django's database stuff that makes it so easy and worthwhile to use. For example, fixtures. In Django, you can include them in your tests and have it All Just Work(TM): https://docs.djangoproject.com/en/dev/topics/testing/#fixture-loading https://docs.djangoproject.com/en/dev/topics/testing/#fixtur... You can also use them outside of testing, too: https://docs.djangoproject.com/en/dev/howto/initial-data/#providing-initial-data-with-fixtures https://docs.djangoproject.com/en/dev/howto/initial-data/#pr... Fixtures in Flask/SQLAlchemy? Not so much - you have to roll your own (crappy) implementation: http://farmdev.com/projects/fixture/using-fixture-with-pylons.html http://farmdev.com/projects/fixture/using-fixture-with-pylon... http://flask.pocoo.org/mailinglist/archive/2011/3/6/flask-sqlalchemy-and-fixtures/ http://flask.pocoo.org/mailinglist/archive/2011/3/6/flask-sq... Also note that, while I'm picking on fixtures here, Django also has a bunch of other database related features, like introspecting a pre-existing database, and generating a bunch of Model classes from it. Combine that with South and you're 90% of the way there when migrating the data from a legacy system. This has turned into a bit of a rant, but I've seen a lot of half-baked reimplementations in "pluggable" architectures of stuff which Django just gets right.

mekoka 15y ago
It's not a matter of attitude, it's about having tools, evaluating them for what they're doing for you and making a choice. There's always a conscious trade-off. You can't focus on what's good about Django, as if someone picking SQLAlchemy or Werkzeug is a fool at a loss. The same goes for the other libraries that I listed. In my own case, I'm not particularly a fan of opinionated frameworks. I've had my share of griefs with them. Django looked nice, but I easily could identify with the pains those developers went through when dealing with its lack of flexibility at certain corners. I was new at Python, not at web development, I did not need the hand holding, no matter how nice and clever the code was. This was not a one evening process, I read blog posts, forums, perused StackOverflow and even HN. It took weeks. Feel free to take the journey, then tell me it didn't give you pause. Flask is a small framework that is far from pretending to be what Django is. It's not even at version 1, but with its flaws, I'm quite happy with what it's allowing me to do. I don't mind you ranting about my post, just don't assume that I would use Django the way you do. Stuff that you relish might be what turns me off and the beauty of it all is that it's all acceptable.
- anthonyb 15y ago
  I really don't understand the "lack of flexibility" thing myself. I've made Django and Django's ORM and admin do all sorts of weird stuff, and it's much easier to build on top of that than to reroll everything, which is what you have to do with Pylons/Flask/Bottle/... And database/fixture set up is something that you will have to do, assuming that you test your app, and that your app is more sophisticated than "I have some strings which I want to upper case". Ditto for working with legacy databases, migrating data, bla bla blah. The default option from what I've seen tends to be to set your DB up once and hope for the best, or else repopulate it after every test. Both of these options work great(ish) when you first start your project, but then grind you down six months later when your test suite takes an hour to run. A decent ORM, along with in-memory SQLite and fixture setup is generally what's settled on for most integration suites that I've seen, and Django does that out of the box. Also - a minor nit, but WTForms and Jinja2 are based on Django's form and template libraries. Switching to them doesn't get you that much - they certainly don't replace any of Django's core infrastructure. And I've found SQLAlchemy to be basically unusable unless you use the new 'declarative base' stuff, which looks suspiciously similar to... Django's ORM :)
  - j-kidd 15y ago
    Your comment, in particular the part about SQLAlchemy, reads a lot like the blub programmer.
    - anthonyb 15y ago
      Ad-hominem much?
  - zzzeek 15y ago
    > And I've found SQLAlchemy to be basically unusable unless you use the new 'declarative base' stuff, which looks suspiciously similar to... Django's ORM :) I can relieve your suspicions as I never looked at Django's ORM at all when designing declarative. It's merely poking normal SQLAlchemy attributes, all of which existed before Django was ever released, onto a class. I can assure you active-record style class mapping is not an idea Django invented.

mekoka 15y ago

It's not a matter of attitude, it's about having tools, evaluating them for what they're doing for you and making a choice. There's always a conscious trade-off. You can't focus on what's good about Django, as if someone picking SQLAlchemy or Werkzeug is a fool at a loss. The same goes for the other libraries that I listed. In my own case, I'm not particularly a fan of opinionated frameworks. I've had my share of griefs with them. Django looked nice, but I easily could identify with the pains those developers went through when dealing with its lack of flexibility at certain corners. I was new at Python, not at web development, I did not need the hand holding, no matter how nice and clever the code was. This was not a one evening process, I read blog posts, forums, perused StackOverflow and even HN. It took weeks. Feel free to take the journey, then tell me it didn't give you pause. Flask is a small framework that is far from pretending to be what Django is. It's not even at version 1, but with its flaws, I'm quite happy with what it's allowing me to do. I don't mind you ranting about my post, just don't assume that I would use Django the way you do. Stuff that you relish might be what turns me off and the beauty of it all is that it's all acceptable.

anthonyb 15y ago
I really don't understand the "lack of flexibility" thing myself. I've made Django and Django's ORM and admin do all sorts of weird stuff, and it's much easier to build on top of that than to reroll everything, which is what you have to do with Pylons/Flask/Bottle/... And database/fixture set up is something that you will have to do, assuming that you test your app, and that your app is more sophisticated than "I have some strings which I want to upper case". Ditto for working with legacy databases, migrating data, bla bla blah. The default option from what I've seen tends to be to set your DB up once and hope for the best, or else repopulate it after every test. Both of these options work great(ish) when you first start your project, but then grind you down six months later when your test suite takes an hour to run. A decent ORM, along with in-memory SQLite and fixture setup is generally what's settled on for most integration suites that I've seen, and Django does that out of the box. Also - a minor nit, but WTForms and Jinja2 are based on Django's form and template libraries. Switching to them doesn't get you that much - they certainly don't replace any of Django's core infrastructure. And I've found SQLAlchemy to be basically unusable unless you use the new 'declarative base' stuff, which looks suspiciously similar to... Django's ORM :)
- j-kidd 15y ago
  Your comment, in particular the part about SQLAlchemy, reads a lot like the blub programmer.
  - anthonyb 15y ago
    Ad-hominem much?
- zzzeek 15y ago
  > And I've found SQLAlchemy to be basically unusable unless you use the new 'declarative base' stuff, which looks suspiciously similar to... Django's ORM :) I can relieve your suspicions as I never looked at Django's ORM at all when designing declarative. It's merely poking normal SQLAlchemy attributes, all of which existed before Django was ever released, onto a class. I can assure you active-record style class mapping is not an idea Django invented.