FWIW, I've been using Flask. It seems to be the one having the most traction and support these days.<p>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).<p>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.<p>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.<p>[1] <a href="http://tom.preston-werner.com/2010/08/23/readme-driven-development.html" rel="nofollow">http://tom.preston-werner.com/2010/08/23/readme-driven-devel...</a><p>[2] <a href="http://jonasgalvez.com.br/Writings/Casual-Testing.html" rel="nofollow">http://jonasgalvez.com.br/Writings/Casual-Testing.html</a>
Not to diminish the contribution from shabda - but what would really interest me is hearing about these frameworks from the perspective of someone who has launched and maintained a complex system, not a toy app.
What is the point of making toy apps? Make a complex app that evolves over a period of 2 or so years, and then tell me how it went. Much of the time the framework where it is easiest to make a toy app is the one that has lots of hidden, implicit assumptions that come back to fuck you when you need the flexibility to do something that violates those assumptions.<p>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.
Neat, but you should check out PEP 8 at some point. An empty line between a decorator and the decorated function (flask) is confusing, and whitespace in keyword arguments just looks off.<p><a href="http://www.python.org/dev/peps/pep-0008/" rel="nofollow">http://www.python.org/dev/peps/pep-0008/</a>
I hope there's going to be a followup discussing the strengths and pitfalls of each, along with the the original specifications of the app, so we can see where a framework imposed limitations or even provided a better approach to implementing a feature.
This is hardly an apples to apples comparison. Pyramid (ex-Pylons) and Django are "full-stack" frameworks with everything incuding the kitchen sink. App Engine only runs on App Engine, so probably isn't that relevant anyway. The others are (by their own descriptions) micro-frameworks, suitable for smaller applications with 10 URLs or so.<p>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.
I realize that scalability probably wasn't a concern when you made these demos.. but it doesn't look like any of these can handle many concurrent requests (incoming, or outgoing to facebook).<p>Are any of these frameworks even compatible with the event driven mechanisms like twisted, tornado, etc?<p>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)
Thanks for the post but I find the title of the link a bit confusing <i>"Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ..."</i><p>I'm not sure what you're comparing.