Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...(agiliq.com)
agiliq.com
Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...
http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/
10 comments
loosely coupled components are the way to go
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?
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?
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.
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.
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.
- 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.
+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.
(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.
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.
You should maximize the use of ready-to-use extensions once you know how things work, whether yours or the community's.
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.
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.
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.
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.
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.
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.
That would be really interesting to see the details required for each framework in comparison to each other.
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.
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.
http://www.python.org/dev/peps/pep-0008/
http://www.python.org/dev/peps/pep-0008/
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.
I plan to do another set with a complexer app, and then do an actual comparison.
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.
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.
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.
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.
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.
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).
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)
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)
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.
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.
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/
http://flask.pocoo.org/docs/deploying/others/
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.
web2py deserves a place on the list. I've found it to be more productive than django.
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!
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!
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 :)
It's in the github repo.
that example needs to be cleaned up - it includes databases, error tickets, sessions, etc, which makes it look more complicated than the others.
Thanks for the post but I find the title of the link a bit confusing "Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ..."
I'm not sure what you're comparing.
I'm not sure what you're comparing.
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...
[2] http://jonasgalvez.com.br/Writings/Casual-Testing.html