Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
agiliq.com
agiliq.com
But I think frameworks are not that important. I use Flask mostly for its HTTP request handling functionality. But everything else is my own (e.g., the overall setup, configuration etc).
I think what's most important is understanding that loosely coupled components are the way to go. Know how your scripting language loads and manages modules and try to get to a simple convention on how to organize your code. Minimize the use of ready-to-use extensions and just try to effing know. how. things. work. Glue code together yourself. Document religiously how you did it[1]. It'll save you a world of trouble.
The one tool that has been central to my web development work in Python is pretty much framework-agnostic: Fabric. My projects start with a single fabfile.py and and lib/ directory. I do most of the prototyping in the fabfile.py, which serves as a sort of adhoc testing sandbox[2]. And then I start adding request handlers and writing markup/css. With this approach, whether you're using Flask, webpy or Juno (my faves) is irrelevant. But sticking with Flask might give you a more enthusiastic and active community nowadays.
[1] http://tom.preston-werner.com/2010/08/23/readme-driven-devel...
On the other hand, for this specific app -- bottle, itty and juno all look very similar to the app made with flask. For whatever reason I find this very Pythonic.
This is the _main_ reason I chose Flask to work on a new project. After using our in-house proprietary framework for a year and a half, I wanted to see if I could do any better. But the HTTP request part sounded boring. Enter Flask: it let's me grow the framework into exactly what I want it to be.
I disagree. Had you added "in some situations" I wouldn't.
The point of the frameworks, which are heavily coupled components with many constraints, conventions and hidden parts of functionality is rapid prototyping. That means that you can go from 0 to something quickly without knowing all the details. For a large class of use-cases the ability to get something out there fast is more important than the technical debt you may incur by not knowing how everything is loaded. This is the case for a lot of new products, startups and such.
On the flipside, if you have a very solid spec of what you're building (for example, if you are re-writing an already-existing piece of software with a browser-level test suite as spec so that it is easier to scale) then loosely coupled components are likely the way to go. And yes, as soon as scale comes into question loosely coupled components that you understand well are the way to do it. This just isn't always the case.
Secondly, it is not clear whether the frameworks get in your way that much. I remember reading a blogpost about a shop replacing django bit by bit until there was no django. That seems pretty cool. On the other hand, there is disqus, which used django from the get-go, I think, and haven't swapped it out, but just built a lot of tools around it. On the third hand, there is probably a lot of sites that start with loosely coupled components and keep refining. They are all valid approaches. At the time you are starting it is usually unclear how to go about it.
In general I agree that people should try to understand how their tools work, but there are only so many hours in a day, y'know?
Personally, my experience is that for rapid prototyping, there's nothing better than starting with the absolute minimum possible, and with a full-blown monolithic framework, the absolute minimum is, more often than not, too much.
I prefer starting a project with a couple of files, like fabfile.py and app.py, than starting a project with a bunch of directories and tons of blueprinted configuration files. It's hard to explain why, I just feel it's a lot easier for me to evolve an idea, from a small prototype to a finished product, with this approach. I guess the cognitive signal to noise ratio is just higher that way. I know many people share this feeling, otherwise Sinatra and all these Python microframeworks wouldn't be getting so much attention.
I think a good framework is like a good government, consistent, helpful, but with self-limiting interference. I think documentation is way more important than features. I'll take a well written web development patterns guide over a framework that does it all for me under the hood any day. The thing is that Flask tries to be both. Flask's documentation is absolutely fantastic. It is no surprise, of course, since it comes from the same guys who made the Sphinx documentation builder.
I like conventions. I just don't think they ought to be mandatory. I see Flask as a genome of web applications, with pre-defined solutions and information on how to accomplish a series of things, but my application itself doesn't have to be a grown organism from the beginning, it can start small, like an embryo, and slowly grow in size. Flask gives you enough flexibility to employ conventions but also do things differently, to invent your own way, when you feel that you need to.
- Use a framework that has adequate components that are well integrated and quick to get off the ground, but where you might hit snags with the bundled components later and have to monkey patch them to continue working within the framework.
- Use a micro-framework where you can choose to glue in excellent components (SQLAlchemy, for one) at the cost of the time spent writing glue code.
I personally really like django. Even though it is considered monolithic, I agree with a lot of design decisions and a lot of the components are "just the right amount" extensible. Most of the third party apps that I use work well.
That being said, I'm using flask now and enjoying it :) I hit a snag pretty early with django's ORM [1] and couldn't figure out a way around it other than raw SQL. SQLAlchemy's flexibility won out in the end. I chose flask over other micro-frameworks because of its documentation, extensions, design decisions, mailing list seemed active etc.
Now that I have switched from django, I'm really enjoying the flexibility of picking up 3rd party modules (or flask extensions) and using them instead of having the decisions made for me. It is very marginally more work than django.
[1] Query multiple tables (books, cds {subchildren of products}) for products that were updated in the last month.
Using an abstract base table (products), django's ORM required multiple trips to the DB. Using a concrete base table meant that getting any single product would require a join. SQLAlchemy handles this scenario with unions.
Not complex, but should give me a chance to test the ORM, Session, Cookies etc.
However, the devil is in the details. Once you start managing something sufficiently complex you start to see what details constrain you in bad ways and such. I'd guess that you don't get to that point until way after you launch.
The application I'm running is large, complex, and has quite a few moving parts.
I run it under mod_wsgi in Apache and use the Paster server when developing on my local machine. I particularly love the unit testing harness for Nose that Pylons provides.
Having dealt with python frameworks for several years and developed several complex apps, I'm not willing to use anything other than werkzeug. It's lightyears ahead of than else out there (flask is werkzeug wrapped in shit you don't need with the intention of making it more popular). Pylons is also very nice, although it tries to do too much for you, and has too much magic for my taste. The context-local request and response objects in pylons are a double edged sword that I find cuts the wrong way too often.
It's possible to use both in a project, for example we at Smarkets use Django for the main site (as we have tonnes of URLs and complexity), and use Flask for a RESTful API to our search engine. I wouldn't dream of swapping or comparing them: they both do their own job very well.
The others are (by their own descriptions) micro-frameworks, suitable for smaller applications with 10 URLs or so.
I don't think the attribute micro relates to the size of the projects you can create with these frameworks but rather the way they are written: Keep the core small and rely on external libraries for specific functionality.
Are any of these frameworks even compatible with the event driven mechanisms like twisted, tornado, etc?
I'm having to pick up Python since a lot of the webapp infrastructure at the startup I joined is Python/Django and I haven't really liked it so far, especially since everything we do would benefit from being done in an event loop (tons of IO to background services that make web requests block)
One of the most popular WSGI servers these days, gunicorn, has a simple configuration option that lets you switch on Eventlet transparently. Or you can use something like Spawning [http://pypi.python.org/pypi/Spawning], which is built from the ground up specifically to use Eventlet.
web2py both (a) sounds way way too much like web.py, which predated it, and (b) it sounds like it's a successor to it -- which it is not, and (c) sounds like it's a conversion tool of some kind (following the whole "foo2bar" pattern in program naming).
Whereas 'gluon': some small thing which binds the universe together. And it has personality!
I'm not sure what you're comparing.