Very nice! Would you add a web2py example too? I just made it:

Controller:

import urllib
from gluon.contrib.simplejson import loads

def index():
endpoint='http://graph.facebook.com/search?q="so%20starving&type=post'
def get_data(): return loads(urllib.urlopen(endpoint).read())['data']
data = cache.ram(endpoint,get_data,30*60)
return dict(data=data)

template:

{{extend 'layout.html'}}

{{ for post in data: }}






{{=post['message']}} : {{=post['from']['name']}}



{{ pass }}


(assuming it is ok using the default layout.html)
It is [running here](http://web2py.com/fmld) and the source code is here [as a zip](http://web2py.com/fmld/static/fmld.zip) or [as a w2p](http://web2py.com/fmld/static/web2py.app.fmld.w2p).

Would you consider writing your thoughts about writing in each of the frameworks? Which was easiest to user and which was the most fun to work on?

@massimo lol! dude stop poking around doing one man publicity pitches here there and everywhere.

You left out CherryPy??? It's the best minimalist framework.

I was wondering why pylons was left out and I would appreciate a brief summary of your experience with all those framework.

If you fork on github and send me a pull request, I will include Pylons and CherryPy.

No TurboGears 2 ? :(

Our website offers the Cheap Rosetta Stone on sale,such as these very popular kinds: Rosetta Stone Spanish,Rosetta Stone German,Rosetta Stone Italian and so on,besides,there are many friendly customers who left useful Rosetta Stone Reviews,which maybe the good guide for you!
All the Rosetta Stone are 100% satisfaction guaranteed,and free shipping.We guarantee its quality,and all money will be refund if the goods are not satisfied.
welcome to make a purchase.

so guys, which is the best, I'm hesitating between Flask and Tornado for a quite simple project, I've used web2py and I like it

The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x: http://bit.ly/cnYk3x

The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x: ... http://bit.ly/aX06Vp pt

The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x# ... http://bit.ly/crrI0B pt

Web app in python frameworks http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/

I am so starving: #Web app in python frameworks. - The Agiliq Blog http://bit.ly/aAYajF

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/9Py8yn

I'm so starving es una aplicación web escrita 11 veces en 11 frameworks python. Gran idea. Muy educativo. http://goo.gl/UdWWB

RT@gsempe: The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/aAYajF

RT@morenosan: I'm so starving es una aplicación web escrita 11 veces en 11 frameworks python. Gran idea. Muy educativo. http://goo.gl/UdWWB

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, jun http://bit.ly/aDohEC (http://bit.ly/cR07Br) #guru

RT@johl: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

RT@johl: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

That would be really interesting to see the details required for each framework in comparison to each other.

Thanks to WSGI you can. For example, here's a handy page in Flask's (outstanding I might note) documentation on how you can run it on Tornado, Gevent and Gunicorn:http://flask.pocoo.org/docs/deploying/others/

I've built my startup entirely in Python + Pylons (1.0). Pylons is wonderful, I really like it a lot and I'm excited about its future too (move to Pyramid which is basically repoze.bfg).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.

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.http://www.python.org/dev/peps/pep-0008/

You should maximize the use of ready-to-use extensions once you know how things work, whether yours or the community's.

loosely coupled components are the way to goI 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?

Just a remark.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.

+1 for Flask. It very much gets out of your way. Interestingly it still feels like you have it both ways (batteries included but loosely coupled) as the series of extensions are high quality thin wrappers for good libraries - namely Babel, Fungiform and SQLAlchemy. For me this was a great introduction to these aforementioned libs.

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.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.

(Flask for its HTTP request handling functionality)++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.

Funnily enough, most of these frameworks' caching tools will set the appropriate outgoing headers for you. Which I'm pretty sure you know. I'm pretty you also know that "just set the HTTP cache headers" covers only a tiny fraction of the actual problem.

I guess you meant "not fiscally viable to use multiple machines" because I am quite sure last time I looked a lot of the queue packages came free.

I am so starving: Web app in python frameworks. http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/

RT@charlvn: I am so starving: Web app in python frameworks. http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://goo.gl/UdWWB

I am so starving: Web app in python frameworks. - The Agiliq Blog http://dlvr.it/8CfWH

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, jun http://bit.ly/aDohEC (http://bit.ly/cR07Br) #guru

Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

RT@ActiveState: Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

RT@ActiveState: Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

@chglz tambien, voy a subir a github las cosas algo mas o menos así http://bit.ly/csaVbz

RT@newsyc100: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, jun http://bit.ly/aDohEC (http://bit.ly/cR07Br) #guru

Yeah, I also prefer gluon. It had to be changed due to a copyright issue from what I gather. That said, I could give a hoot what a framework is named if I get work done quickly with it :)

that project's choice of name, web2py, drives me apeshit. i much preferred it when it was called gluon.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!

web.py is similar in philosophy and verbosity, and probably older as well

You have a point. Let me elaborate my thoughts on Flask a bit further.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.

You have a point. Let me elaborate my thoughts on Flask a bit further.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 not 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.

I personally see django vs flask (or other microframework) as this:- Use a framework that has adequate components but they 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.

I personally see django vs flask (or other microframework) as this:- 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.

RT@newsycombinator: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

RT@newsycombinator: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

RT@newsycombinator: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/9UoTsc http://ff.im/-tlyVN

that example needs to be cleaned up - it includes databases, error tickets, sessions, etc, which makes it look more complicated than the others.

I apologize if I gave that impression. I intended to mean that it is my impression that frameworks encourage the use of talking to memcached directly instead of encouraging the use of HTTP caching. I believe that it would be better if web developers started with HTTP caching (and a caching proxy) and only relied on memcached directly when absolutely needed.

I think you'll find that many of the authentication and personalization problems will go away if you put the client's state in their browser and don't keep track of it on the server. If you'd look at the type of sites we build, news sites, most of the content is common among all users. The personalization stuff can be either stored in the browser using localStorage, Dojo.storage or cookies and inserted using javascript. That'll cut out the need to personalize the page on the server. If the personalization is not done on the server, then the content of the page becomes common among all users. Slap a two second expiration on it and Varnish in front of it and tada, Django doesn't have to mess deal with it for a few hundred requests. Other things, such as personalized lists of stories can be fetched on-demand using AJAX (if it needs to be included on a HTTP cached page). If it's personalized, google will never see it so there's no real reason to not pull it in using AJAX. Since the personalized list of stories is now a separate resource from a common list of stories. We can use the vary header to cache that page based on the auth tokens. If you're targeting a platform that can't keep local state, like a dumb phone, then you'd want to create a state-full layer on top of your stateless site/web service. You'd piece together data while fetching it through the proxy layer. All the common data will be cached and fetched really fast and all the personal stuff will be be as slow as it would be if fetched via AJAX. Invalidation is a hard problem. Often, the solution is to keep the expiration times short enough so that stale content doesn't stick around. The same is often true with memcached. I don't find myself having to delete keys from memcached because the with the data I'm caching, eventually consistent is good enough.

Have a look at [this video](http://video.google.com/videoplay?docid=6297126166376226181) done a few years ago by a guy at NASA comparing various web frameworks including Java and Ruby ones. It is a nice presentation style and you may find some of the things he compares useful to look at too (restarts, errors, auth etc).

Writing a Web app in multiple python frameworks - Comparisons... - http://su.pr/1C5gI5

@marcfowler I wouldn't recommend Django, you'll start off with all their components, then rip them out later. Look here http://bit.ly/d2FLlc

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/drWFMR

RT@justinvincent: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/drWFMR

RT@justinvincent: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/drWFMR

RT@ActiveState: Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/cxrYxN

? I am so starving: Web app in python frameworks. - The Agiliq Blog http://is.gd/gZXBD

You fail at reading comprehension, both in the title and the linked article.

I think what you want to do here is *look at how this stuff is actually implemented*. For example, Django's cache middleware and its caching decorator for individual views (which are actually the same code) set the outgoing `Expires` header (and `ETag` if you're using those, and `Last-Modified` when needed). This gets you best of both worlds: things which respect HTTP caching will respect those headers. And things which don't will still get responses served out of server-side cache. Which is necessary: if you're under the impression that we live in a happy world where every client respects HTTP caching, brother, I've got some bad news for you...

I'll have to add that the test I'm doing is not a comparison of framework speed but the failure of the way we all do caching at the moment.

I am so starving: Web app in python frameworks. - The Agiliq Blog: http://bit.ly/fi6GEB #delicious #popular

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/f0E6FX

I am so starving: Web app in python frameworks. - The Agiliq Blog http://dlvr.it/B3XzF

I am so starving: Web app in python frameworks. - The Agiliq Blog http://dlvr.it/B3Ybb #delicious

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/i8CDs9

via Del.icio.us : I am so starving: Web app in python frameworks. - The Agiliq Blog: http://bit.ly/aAYajF #social #networking

@krishnaroskin Flask. Or read http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/

Comparing #python web framework http://bit.ly/hTY3M3