Flask 0.7 Released (Python Web Framework)
flask.pocoo.org
flask.pocoo.org
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.
For those of you who are writing apps in Flask, how do you guys manage changes in DB schema ?
Rails and Django emerged at a time when RDBMS ruled, and they were both built around an ORM. Now you have more database options that have less of an impedance mismatch, but because Rails and Django are so ORM-centric, forgoing the RDBMS in favor of another option means you now have a framework mismatch.
Graphs are a much more elegant way of storing relational data. With graph databases you don't have to mess with tables or joins -- everything is explicitly joined.
For most Web development projects, I have shifted from a relational database to a graph database as the primary datastore, and use Redis, Memcached, and MongoDB for specialized purposes when called for.
Neo4j Community Edition (http://neo4j.org/) is open source and now free, and pairing it with the TinkerPop stack (http://www.tinkerpop.com/) is ideal.
With Neo4j you can now store 32 billion nodes (http://blog.neo4j.org/2011/03/neo4j-13-abisko-lampa-m04-size...) with 2 million traversals per second (http://www.infoq.com/news/2010/02/neo4j-10), and you can use Gremlin with it (the graph traversal language), which let's you calculate PageRank in 2 lines -- to see what you can do with Gremlin, check out this 10 min screencast (http://www.youtube.com/watch?v=5wpTtEBK4-E).
For tabular data, relational databases rock. But the relational model doesn't align well with object-orientated programming so you have an ORM layer that adds complexity to your code. And with relational databases, the complexity of your schema grows with the complexity of the data.
The graph-database model simplifies much of this and makes working with the modern-day social graph so much cleaner. Graphs allow you to do powerful things like find inferences inside the data in ways that would be hard to do with relational databases.
There is an open-source Python persistence framework in the works called Bulbs that connects to Neo4j through the Rexster REST server, and there are binary bindings in the works as well. There is also a Python open-source Web development framework for graph databases called Bulbflow that is built on Bulbs and Flask, which will provide stuff like authentication and authorization, in a graph-DB way. Both frameworks should be released in the next few weeks.
And Rails & Django were (at the time) also built around a specific ORM. Compare this to Catalyst, which also came out same time as Rails & Django, was built from the ground up with an agnostic model and thus could use any ORM available or easily adapt to different data models.
For my current side-project, I'm actually building a thin ORM layer that basically handles migrations through hand-written SQL scripts.
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?
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.
Markdown/Textile; in the Python world people mostly use Restructured Text, not least because of its privileged position in docstrings.
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
It's built over Mako templates, so its faster and far more flexible than one built against the Django template markup.
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.
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.
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.
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.
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.
That's probably why he just finds it easier to use django.
I don't know about you, but I've personally found that after a few months of working on an application the models tend to be pretty stable.
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.
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.
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.
* Dancer (http://perldancer.org/)
* Mojolicious::Lite (http://mojolicio.us/)
* Squatting (http://p3rl.org/Squatting)
* Web::Simple (http://p3rl.org/Web::Simple)
PS. Here is a presentation doing a loose comparison between Dancer & Flask called "Dancer for Python programmers" (http://www.slideshare.net/xSawyer/perl-dancer-for-python-pro...)
Its simplicity is just amazing, and it's really fun to work with.
Furthermore Bottle does magic that is frowned upon by some people.
Can you elaborate?
By now I really would like to see them merge, but Bottle wants to stick to the design idea of just having one file which Flask will never be able to do because of the dependencies.
If you use Flask you create the application object explicitly and pass it the name of the module, relative to which Flask looks up resources.
Reading the source, I see no evidence of this.
https://github.com/defnull/bottle/blob/master/bottle.py#L161...
https://github.com/defnull/bottle/blob/master/bottle.py#L263...
You can override it but you would have to do that for every call to `template` or by monkey patching `TEMPLATE_PATH`.
For the most part though, Flask is very magic free and the source is small enough to quickly figure out whats going on.
Bottle runs on Python 2.5+ and on Python 3.x.
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.
connection[app.config['MONGODB_DATABASE']].mycollection.find_one()
import unittest
def setUp(self):
myapp.app.config['MONGODB_DATABASE'] = 'test'
self.app = myapp.app.test_client()
def tearDown(self):
# can clean up here, e.g.
connection.test.drop_collection('mycollection')