[superxor]

Though the article is new to me I don't understand the context of this submission.

(Never using web.py and not being fully aware of Django's status in 2005) I see that overall they seem to have faired well. All you need is a settings.py file to run a Django app. The templating is slow performance-wise but pretty expressive.

I love that the Django community as a whole is pretty responsive to criticism. The 'Why Django Sucks' talk at DjangoCon is an example. My biggest complaint was the horrible User model (you cannot not have 'username' for a Django app using the User model). But they've fixed it now. The major complaint against Django is that it is monolithic, but the devs have worked hard to keep the system decoupled allowing one to replace most modules. But if you want something small Django is not the one for you I guess, and there is nothing wrong in it. One size fits all is never possible to achieve and not a good solution too.

[raverbashing]

Django 1.5 has pluggable user models (at last!)

If you're looking for a nice Python web framework, try Pylons/Pyramid

Pylons is loosely coupled. Not Django.

Django is not bad and it certainly makes it easier for 99% of projects out there (CMS style). But for the 1% it's a pain.

[TazeTSchnitzel]

I'd suggest Flask. Flask is a very lightweight microframework, yet it contains everything you need to write a web app in Python. If you want to write everything in one file with Flask, you can. If you need several files, you can do that. You can use proper views if you want. Or not.

[anthonyb]

It doesn't contain everything you need at all - that's why it's called a microframework.

If you want to use an ORM, or have database backed sessions, or user logins, you need to write all that yourself. For example: http://flask.pocoo.org/docs/patterns/sqlalchemy/

Depending on what you're doing, that might be a good thing - but I find writing things which are already included in Django pretty annoying.

[recuter]

Depending on the complexity of the project it might take you just as long to read how a monolithic framework decided to tie everything together (warts and all, because that will inevitably have historical cruft and technical debt).

The extensions were mentioned; User logins for example are just a "pip install Flask-Login" and "from flaskext.login import whatever" away. I had reason to roll my own, ~100 simple lines that were easily plugged.

There are pros and cons, neither is "better", the right tradeoff depends on what you're making.

[anthonyb]

Well, except that the login process for Django has a lot more people looking at it, and you know that the parts are going to work together pretty well.

For example, Flask-Login (https://github.com/maxcountryman/flask-login/blob/master/fla...) imports md5 and sha1 - not a very good sign. How do I make it use something sane? Well, there's Flask-Bcrypt, which provides bcrypt hashing... except that it makes no mention of Flask-Login or how to integrate it. Flask-Login also doesn't mention Flask-Bcrypt.

So... you're back to hacking on or digging into Flask-Login to figure out how it works and making it use Bcrypt or some other hashing algorithm.

Wait - I just realised that Flask-Login doesn't handle storing user data or models, or checking passwords, just logging them in. So what do I need for that? Is that Flask-Principal? And just WTH is an IdentityContext, anyway?

  An IdentityContext is the context of a certain identity
  against a certain Permission. It can be used as a 
  context manager, or a decorator.

You see why people use Django now? :) Sometimes you just want the standard user-logging-in-and-storing-in-the-database without having to write it yourself.

[wfn]

True that.

However, the Extensions library [-1] (which is not strictly speaking part of Flask) provides quite a lot of functionality - apart from your referred SQLAlchemy (which does the job well in our backend), there's a nice API generation factory [0] [1] and other neat stuff. For quite a lot of intents/purposes, flask extensions will do the job. But in the end of course it is a microframework. (From limited personal experience, a very neat general-purpose microframework nevertheless!)

[-1] http://flask.pocoo.org/extensions/ [0] [1] A particularly sexy example that simply uses models from SQLAlchemy (from the quickstart in [0]): manager.create_api(Person, methods=['GET', 'POST', 'DELETE']) manager.create_api(Computer, methods=['GET'])

where Computer and Person are DB models easily defined with the help of SQLalch.

(This is not to counter (there isn't anything to be countered, just providing links / luring people..)

[brass9]

Flask fan here.

Flask is not a "micro" microframework per se.

It provides a thin facade over werkzeug - which is anything but lightweight or micro.

[irahul]

* Flask fan here. Flask is not a "micro" microframework per se. It provides a thin facade over werkzeug - which is anything but lightweight or micro.*

Another Flask fan here. If Armin says Flask is micro, and other frameworks which aren't considered micro are far larger than Flask, what makes Flask not a micro framework?

[TazeTSchnitzel]

>It doesn't contain everything you need at all - that's why it's called a microframework.

I said everything you need to make web apps in Python, and I stand by that. Maybe it doesn't have an ORM or user account management, but for my purposes, it's great for small apps.

[StavrosK]

Flask is the longest-running April fool's joke I know of.

[rdtsc]

Having looked at both web.py nad Flask, web.py seems more elegant at first glance.

I like the mapping of a resource to class and method names to class method.s I am not sure I like Flask's method handling and having to do if ... elif .... else (maybe I just found some bad example, so please correct me).

Also url dispatching at the top makes it easier to understand what's going on rather than having it spread to each of the decorators somehow.

[stesch]

Yes, the decorators. One of the problems of new web frameworks like bottle.py, too.

[hellsten]

Flask and Sinatra are great. Easy to learn and easy to customize. They have stable APIs, unlike big frameworks like Rails and Django. This means you don't have to worry about what happens when you upgrade your application to the latest version.

[raverbashing]

Django is much more compatible between versions than Rails

Functionality added usually doesn't break what currently works (except maybe for bugs fixed)

[Alex3917]

"Pylons is loosely coupled. Not Django."

Django isn't loosely coupled by default, but it can be used in a relatively loosely coupled way. E.g. you can easily use your own SQL and templating engine. Yes you can't just hot swap in a new web framework without rewriting the core app code, but that's the case with every framework.

[redDragon]

Love Django! mozilla has been using it for a fair bit of time now.