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.
Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
11–20 of 33 posts
Re: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
#12I 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). 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'…
These examples can be made to run in a completely evented style with no code changes using Eventlet. I use this for pretty much all of my projects these days: http://eventlet.net/
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.
Re: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
#13I 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). 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'…
Afaik, All of these are WSGI. So You would be them behind a WSGI container, so incoming concurrent requset wont be a problem. Outgoing requests should be fairly rare with Data from FB cached.
Re: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
#14I 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.
I plan to do another set with a complexer app, and then do an actual comparison.
Re: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
#15Not 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.
Probably over the next weekends, Ill do a basic blog in these frameworks. Not complex, but should give me a chance to test the ORM, Session, Cookies etc.
I think you'll find that all of them are very similar in terms of ORM, Session, Cookies, etc -- they are, more or less, the same toolbox.
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.
Re: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
#16This 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.
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.
Re: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
#17FWIW, I've been using Flask. It seems to be the one having the most traction and support these days. 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 l…
Flask looks delicious.
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.
Re: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
#18What 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.
Re: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
#19Neat, 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.
Re: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
#20This 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. It's possible to use both in a project, for example we at Smarkets use Django fo…
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.