The benefits of using Django include not having to rebuild a lot of boiler plate features again and again. Things like the admin panel for example. When I used web.py I always had to build some kind of way to manage users easily. Login pages, logout pages, error pages.
I do not know much about Flask and it looks like it has some bare bones middleware and context processor tools, but it doesn't look like it does much more than what web.py offered, well except for all the testing tools (which look pretty cool).
Sure the article has a good argument about separating components, but before you propose your alternative you should include all of those features (decoupled I suppose) that Django does for you already. In addition the patterns page[1] on the Flask documentation is basically a cookbook for things that Django already does, and by the way encourage the one code base architecture this presentation argued against.
from contextlib import closing
def init_db():
with closing(connect_db()) as db:
with app.open_resource('schema.sql') as f:
db.cursor().executescript(f.read())
db.commit()
> not if you're using sqlite, since alembic doesn't seem to try too hard supporting it.
Because its brand new, written by pretty much one person (I'll give you a hint, it's me), and also sqlite barely supports migrations itself (http://sqlite.org/faq.html#q11). You're trolling pretty hard in this thread, maybe you should let other toolsets besides django have a chance.
Sorry, wait a second. You're comparing a feature built in to the core of django to something brand new that has a support team of one person and accusing the other guy of trolling?
I'm sure your code is fine, but you can't possibly argue that it is on par with a major component of a major framework and be taken seriously.
alembic and sqlalchemy are not only on par with django's tools, they are generally superior. This isn't just my opinion, here's Alex Gaynor, Django core committer, saying the same thing:
Yet the developmental resources SQLAlchemy and Alembic are a tiny fraction of what Django has. It's the tremendous gravitational pull of Django and the habits of its community writing things hardcoded to Django that suck the life out of other projects in the Python community.
You misread him. He's saying that it's unfair to compare alembic, written solely by him, to something built into Django and debugged by lots of people.
Which is fair enough IMO, but it's not really convincing me that Flask is a better way to go.
Who needs a one-line schema migration command that can be rolled back when you can just copypaste boilerplate which doesn't do anything nearly as useful or sophisticated and requires you to go and actually write out the table definitions? You're right, dude. Great idea.
I do not know much about Flask and it looks like it has some bare bones middleware and context processor tools, but it doesn't look like it does much more than what web.py offered, well except for all the testing tools (which look pretty cool).
Sure the article has a good argument about separating components, but before you propose your alternative you should include all of those features (decoupled I suppose) that Django does for you already. In addition the patterns page[1] on the Flask documentation is basically a cookbook for things that Django already does, and by the way encourage the one code base architecture this presentation argued against.
[1] http://flask.pocoo.org/docs/patterns/