> Eh, they all solve the same problems. This is really the best summary. It comes down to what your individual team can be more productive with. If it's Django

> Eh, they all solve the same problems. This is really the best summary. It comes down to what your individual team can be more productive with. If it's Django, use Django. If it's Flask, use Flask. > Don't even get me started on the ORM -- why does it even exist when we have SQLAlchemy? There was a time when I thought much the same. But now I am glad for Django's more simple ORM. I've ended up liking ORMs less and less in general. If I'm going to use one, it's only going to be for the more simple queries. For this kind of case, Django's ORM really shines. Even our less technical staffers can get a copy of the DB and run some business analytics queries themselves. For anything else, I'd much rather write the SQL myself. It's not difficult, and you are going to do better than the ORM could. Additionally, no ORM is going to have 100% support for every feature Postgres or MySQL offers. For example, we've made great use of Common Table Expressions. > With Django, what happens when it doesn't work is you find yourself about 13 levels deep in the stack looking at some wrapper class in this giant framework. If you do have to get into a Pyramid component, most of them are actually just individual projects, a single developer can understand the whole thing. Conversely, having a bunch of projects to track and update means breakages can occur in many different places for any given combination of versions. In practice, we haven't found Django to be difficult to run. Quite the opposite, really. It's a cohesive unit. If you run into an issue, you are going to find lots of mailing list/bug tracker posts walking you through the solution in most cases.