This way you get Flask simplicity and elegance, but also you get Rails-like separation of configuration test/development/production environments.
Another misconception people seem to have is that Flask means Jinja2. Fortunately that's not the case, swapping Jinja with Mako is also extremely easy.
Finally, Flask can run on top of any WSGI server, not just a built-in one: at http://mailgun.net we have Flask services running on Tornado and on Paster servers - the thing is rock solid.
I'm always impressed by Flask - especially its documentation. In fact, this seems like a good occasion to have a poke around and build something with it.
On a slightly related note - although jinja2 is already quite compact, I'm a fan of haml and I'm always surprised by the lack of support for it in Python. Is there something I'm missing? Uncanny valley for Pythonistas?
There's a Nemo[1] a "pythonic haml". It doesn't follow the Haml spec exactly, but rather tries to take the good parts and apply them to something suitable for Pythonistas.
It's built over Mako templates, so its faster and far more flexible than one built against the Django template markup.
You can roll out your own or use one of the existing translators which translate from haml to jinja2 syntax.
Do you use slim templates? I recently wrote a hand rolled recursive decent parser which translates slim to jinja2 - https://github.com/thoughtnirvana/slimish-jinja2. Jinja2 supports extensions and after adding this extension, you can write slim templates which will be translated to jinja2 on the run.
The lexer and parser are simple enough - you can make code changes or roll out your own if you want to.
There was a Haml-like language called GHRML a while back, but it seems to have disappeared. There is something like it called SHPAML: http://shpaml.webfactional.com/
Though I think Ruby has better markup libraries in general. For example, they have Nokogiri, which is an absolute joy to use for XML parsing. And implementations of Markdown and Textile with actual parsers, whereas Python Markdown and Python Textile are straight regex-using ports of the Perl/PHP versions. It's kinda sad really.
Right now, I'm writing most of my projects in Tornado.. Not because I need the async, but because I wanted a simple web.py like format that was under active development.
Can someone help me understand where Flask fits into things? It would essentially be a replacement for Tornado? What's the advantage of this over Tornado? Ease of use?
I can understand the simplicity argument; I chose to avoid Django because it was too heavy, so I'd love to hear more about how Flask compares.
Tornado is batteries included. Flask uses Werkzeug and Jinja2 and encourages packaging extensions for localization, form processing, ORM's etc.. Flask, Werkzeug and Jinja2 are all Pocoo projects that have a good community around them and excellent documentation. Technically I would not like to argue the superiority of either, although Flask seems to fit my tastes much better.
Flask's use and deployment of "magic" is pretty spot on. For example by making the request object omnipresent (that is flask.request is always bound and has the right context). That way it is not passed around the MVC stack but just imported and introspected when needed.
Flask is probably the "healthiest" project I've encountered.
Can someone help me understand where Flask fits into things? It would essentially be a replacement for Tornado? What's the advantage of this over Tornado? Ease of use?
Pretty much yes to all of this.
I can understand the simplicity argument; I chose to avoid Django because it was too heavy, so I'd love to hear more about how Flask compares.
Flask "feels" more like CherryPy than Django to me, but yes, it's more lightweight than Django and more modular (doesn't define an ORM, etc).
The thing that keeps me from using Flask for any serious work is Django's admin interface. That thing saves me ridiculous amounts of time.
For a web framework(non async run of the mill), I would say Flask has an edge. My Flask stack is:
1. SQLAlchemy for ORM.
2. Jinja2 for templates (flask default).
3. Flask for basic web framework functionality.
4. WTForm for forms.
5. Other extensions as needed.
Flask itself is built on werkzeug which is a clean, high-level wrapper over WSGI. Basically Flask is assembling working components into coherent applications. I have done some applications in flask and I can say it's suited for applications of all size.
Tornado, on the other hand, implements its own templating and orm.
Flask is a simple web.py-like framework that is under active development, and I would argue it's one of the cleanest Python Web frameworks (if not the cleanest) out there.
My current project requires real-time stuff so I started to develop it using Tornado and then decided to switch to the Quora model -- use a traditional Web framework for most things, and connect back to Tornado for the real-time stuff.
Quora uses Pylons, but Pylons reached its end-of-life with 1.0, and it's now Pyramid, which is really repoze.bfd and shares no code with Pylons 1.0.
So I swapped out Pylons for Flask and use Sockeit.IO (http://socket.io/) to connect back to Torando for real-time connections.
In addition to just being really-well designed, Flask has an amazing debugger that makes me more productive, and it's easier to write unittests for Flask because you can write them in a traditional way and don't have to contend with Tornado's IOLoop.
When I switched to this model, the development process sped up considerably.
I really enjoy Flask's simplicity (relative to Django) and light-weightness. It was the first web framework I used, actually. Armin Ronacher & team make quality products.
I actually started diving into Python a few months ago, and after a day or two into it I had already ported a feed aggregator from PHP to Python thanks to Flask: https://github.com/giu/hsr-twitterverse. I've also written a simple paste site using Flask without any headaches.
Its simplicity is just amazing, and it's really fun to work with.
I've used it for small side-projects and liked it. What I would like to know is how to do logging, both day-to-day ("user Joe created") and for debugging (like JSON dumps of objects). It should work both with the built-in server and with gunicorn, for deployment. I looked but wasn't able to find a solution that worked. The documentation mentioned logging facilities, but I found no working examples.
Flask seems nice and simple until you need to access a database such as MySQL. With SQLAlchemy it seems like there's a lot more code needed just to perform simple CRUD operations, whereas Django's ORM is really simple. Is there a better alternative to SQLAlchemy? Is it possible to use Django's ORM in Flask?
I take the occasion to ask here if someone could point or write some documentation on unittest in Flask. I am trying to get that right using mongodb...
They are not ignoring P3. They are laying plans to move to it. Patience is a virtue. I am learning Python 3 and would love to be using Flask and even Django. It will happen. There was a 5 year plan for P3 adoption and we are only half way there.
I think if you looked you'd see that they have indeed looked into Python 3 support and have found it technically inviable without breaking a number of things.
Python 3 was backwards incompatible to 2.6/2.7, and there are very large code-bases comprising things like Django that can't just be carted over part and parcel.
As somebody who's spent time building enterprise-class Django applications for a very slow-moving set of customers (e.g., the Federal government) I'm glad they're not pushing forward faster than the rest of the world.
[+] [-] old-gregg|14 years ago|reply
This way you get Flask simplicity and elegance, but also you get Rails-like separation of configuration test/development/production environments.
Another misconception people seem to have is that Flask means Jinja2. Fortunately that's not the case, swapping Jinja with Mako is also extremely easy.
Finally, Flask can run on top of any WSGI server, not just a built-in one: at http://mailgun.net we have Flask services running on Tornado and on Paster servers - the thing is rock solid.
[+] [-] sandGorgon|14 years ago|reply
For those of you who are writing apps in Flask, how do you guys manage changes in DB schema ?
[+] [-] minikomi|14 years ago|reply
On a slightly related note - although jinja2 is already quite compact, I'm a fan of haml and I'm always surprised by the lack of support for it in Python. Is there something I'm missing? Uncanny valley for Pythonistas?
[+] [-] rlander|14 years ago|reply
The project with the most traction seems to be HamlPy[2], but it's limited to Django templates.
The only generic implementation of Haml in Python that I'm aware of is PyHAML[3], but I have never used it.
[1] https://github.com/Pitmairen/hamlish-jinja [2] https://github.com/jessemiller/HamlPy [3] https://github.com/mikeboers/PyHAML
[+] [-] true_religion|14 years ago|reply
It's built over Mako templates, so its faster and far more flexible than one built against the Django template markup.
[1] https://github.com/9cloud/Nemo
[+] [-] irahul|14 years ago|reply
Do you use slim templates? I recently wrote a hand rolled recursive decent parser which translates slim to jinja2 - https://github.com/thoughtnirvana/slimish-jinja2. Jinja2 supports extensions and after adding this extension, you can write slim templates which will be translated to jinja2 on the run.
The lexer and parser are simple enough - you can make code changes or roll out your own if you want to.
[+] [-] LeafStorm|14 years ago|reply
Though I think Ruby has better markup libraries in general. For example, they have Nokogiri, which is an absolute joy to use for XML parsing. And implementations of Markdown and Textile with actual parsers, whereas Python Markdown and Python Textile are straight regex-using ports of the Perl/PHP versions. It's kinda sad really.
[+] [-] atroche|14 years ago|reply
http://flask.pocoo.org/docs/views/
It's good timing; I was just getting to the stage in my app where I was noticing the need for some view refactoring.
[+] [-] ch0wn|14 years ago|reply
[+] [-] e1ven|14 years ago|reply
Can someone help me understand where Flask fits into things? It would essentially be a replacement for Tornado? What's the advantage of this over Tornado? Ease of use?
I can understand the simplicity argument; I chose to avoid Django because it was too heavy, so I'd love to hear more about how Flask compares.
[+] [-] jokull|14 years ago|reply
Flask's use and deployment of "magic" is pretty spot on. For example by making the request object omnipresent (that is flask.request is always bound and has the right context). That way it is not passed around the MVC stack but just imported and introspected when needed.
Flask is probably the "healthiest" project I've encountered.
[+] [-] stevelosh|14 years ago|reply
Pretty much yes to all of this.
I can understand the simplicity argument; I chose to avoid Django because it was too heavy, so I'd love to hear more about how Flask compares.
Flask "feels" more like CherryPy than Django to me, but yes, it's more lightweight than Django and more modular (doesn't define an ORM, etc).
The thing that keeps me from using Flask for any serious work is Django's admin interface. That thing saves me ridiculous amounts of time.
[+] [-] irahul|14 years ago|reply
1. SQLAlchemy for ORM.
2. Jinja2 for templates (flask default).
3. Flask for basic web framework functionality.
4. WTForm for forms.
5. Other extensions as needed.
Flask itself is built on werkzeug which is a clean, high-level wrapper over WSGI. Basically Flask is assembling working components into coherent applications. I have done some applications in flask and I can say it's suited for applications of all size.
Tornado, on the other hand, implements its own templating and orm.
[+] [-] espeed|14 years ago|reply
My current project requires real-time stuff so I started to develop it using Tornado and then decided to switch to the Quora model -- use a traditional Web framework for most things, and connect back to Tornado for the real-time stuff.
Quora uses Pylons, but Pylons reached its end-of-life with 1.0, and it's now Pyramid, which is really repoze.bfd and shares no code with Pylons 1.0.
So I swapped out Pylons for Flask and use Sockeit.IO (http://socket.io/) to connect back to Torando for real-time connections.
In addition to just being really-well designed, Flask has an amazing debugger that makes me more productive, and it's easier to write unittests for Flask because you can write them in a traditional way and don't have to contend with Tornado's IOLoop.
When I switched to this model, the development process sped up considerably.
For real-time stuff, you could forgo Tornado all together and instead use gevent to deploy your Flask app (http://flask.pocoo.org/docs/deploying/others/#gevent), like some have done with Django and Pyramid (http://blog.abourget.net/2011/3/17/new-and-hot-part-4-pyrami...), but I haven't tried this yet.
[+] [-] jparise|14 years ago|reply
http://flask.pocoo.org/docs/deploying/others/
This lets your leverage Tornado's high-performance IO loop while still developing your web application using Flask.
[+] [-] mattdeboard|14 years ago|reply
[+] [-] giu|14 years ago|reply
Its simplicity is just amazing, and it's really fun to work with.
[+] [-] cageface|14 years ago|reply
[+] [-] retube|14 years ago|reply
[+] [-] hiddenbayes|14 years ago|reply
[+] [-] louis14|14 years ago|reply
[+] [-] DasIch|14 years ago|reply
Furthermore Bottle does magic that is frowned upon by some people.
[+] [-] oinksoft|14 years ago|reply
Bottle runs on Python 2.5+ and on Python 3.x.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] loevborg|14 years ago|reply
[+] [-] Semiapies|14 years ago|reply
[+] [-] dumbphone|14 years ago|reply
[+] [-] dumbphone|14 years ago|reply
[+] [-] viandante|14 years ago|reply
[+] [-] johnpaulett|14 years ago|reply
For testing a MongoDB database, I wrote a simple unittest.TestCase subclass that in the setUp and tearDown, creates and then deletes a test database.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] fakeempire|14 years ago|reply
[+] [-] sigzero|14 years ago|reply
[+] [-] bmelton|14 years ago|reply
Python 3 was backwards incompatible to 2.6/2.7, and there are very large code-bases comprising things like Django that can't just be carted over part and parcel.
As somebody who's spent time building enterprise-class Django applications for a very slow-moving set of customers (e.g., the Federal government) I'm glad they're not pushing forward faster than the rest of the world.