A good article, but I don't want the Flask web framework (http://flask.pocoo.org/) to go unnoticed. I struggled along with Django for a number of months, and since I was just beginning web development I felt like I was fighting the large framework, even to build the simplest app. Upon discovering Flask I found it refreshingly simple, and when I moved on to more complicated applications I found it scaled beyond 'toy' apps. It really is worth a look for any Python developer.
I've used both Flask and Django for apps that are both simple and complex. What I have discovered, is that if I use Flask for a complex app, I need to organize my code in clean components that end up looking like Django. Yes, I can do this more-or-less in a freeform manner with Flask, and even use the "one file for everything" method, but for a complex app, I wouldn't want to. It's too hard to manage.
So, in the end, I end up mimicking the basic structure of a Django project: Models, Views, Forms, Utilities, etc. Yes, different ORM, different Form library, WSGI middleware instead of context processors, etc., but all-in-all, no less complex than had I used Django. It's really to the point that I find it hardly any faster to code in Flask for all but the most basic sites.
I still use Flask for super simple projects that require no Admin interface, such as Personalized URL sites for ad campaigns. So it certainly has it's place.
MVC is a local maxima we found to build complex apps. Complex app will always require complex structure no matter the environment.
I don't want to disagree on something I don't have much experience with, but at the same time, I'd like to hear more about how you build your projects.
(In addition, considering there are two viable options for plug-and-play Flask admin interfaces, I don't know why you made it sound difficult.)
I'm not saying it is more difficult. I'm saying that it's not any less complex by the time you put everything you need together. In other words, it's a wash, so I just use Django instead. Fewer dependencies to install, fewer helper functions to write (because many of them already exist), and more components that are designed to work together.
And then there are other things such as having all of your URLs specified on one place vs. as decorators with your controllers. But that's just my personal preference.
You can sort of maybe use SA with Django, except when all the apps you use depend on it and you have to use SA reflection to get at your data. Sadly, the integration is poor.
I totally agree about the regexes: only a small subset of all routes will ever need regexes, and you can do it explicitly in Flask when needed.
SQLAlchemy has pulled so far ahead of the Django ORM in features and usablility that I hope with the Django 3.0 release they replace their ORM with SQLAlchemy. For all the basic use cases it is pretty easy to add in the Djangoisms to the SQLAlchemy ORM layer.
I don't have the time to organize my thoughts but I would like to pipe up here and say that the it's not fair to call the Django ORM 'terrible'. It's extremely easy to learn and does a good job for a very large chunk of plausible use-cases.
But it does an absolutely terrible job for another pretty large chunk of use-cases, mostly because it's closer to objects than relations.
For example, Django's ORM has no concept of explicit joins for example, which are necessary for avoiding O(n) # of queries in several cases. The only way to do it is to write SQL, whereas with SA the query is trivial to write in Python.
That is not true it is just that the syntax is non-obvious and awkward in my mind.
You can do stuff like Teacher.objects.all().select_related('students') and Teacher.objects.filter(students__first_name='Jill').
The biggest frustration is aggregation though. It has hard and sometimes impossible to add group by and having clauses. Using extra() is very fragile and using values to force the group by is awkward. There is probably no fixing that part of the Django ORM other than just getting rid of it.
There are still joins that are not expressible through its syntax, like outer joins between several unrelated models.
I've been pondering implementing a Django ORM backend that just delegates to the relevant SQLAlchemy functions. I think it may be way harder than it seems, though.
This is pretty much exactly what happened to me. I started building parts of django in Flask in my own weird way (probably complete with anti-patterns etcetera) so I thought why am I doing this when there is a team of highly skilled people dedicated to making another system to do exactly this? So now I use Django. And it is AWESOME.
Anyone have experience with Flask vs. CherryPy? I started using CherryPy a few years ago and really liked it, but recently Flask [which looks conceptually similar to CherryPy] seems to be (amongst minimal Python web frameworks) the more hip and popular choice.
You can use both of them on the same project. The reason is that CherryPy is primarily a web application server, and Flask is primarily a web framework.
(I'm not sure why you would want to do that, because Flask comes with Werkzeug, which is better integrated and I trust its author a bit more.)
Also, I've never seen a better documentation than Flask's.
> (I'm not sure why you would want to do that, because Flask comes with Werkzeug)
Well for one, Cherrypy-the-web-server is actually good enough for production. There is much to be said for the benefits of having the same deployment environment in development and production.
The development server is not intended to be used on production systems. It was designed especially for development purposes and performs poorly under high load. For deployment setups have a look at the Application Deployment pages.
It's worth pointing to Graham Dumpleton's blog [1] -- he seems to be the Python world's web hosting ninja. See the great slide deck [2] from his recent talk on hosting python web apps [3] -- the deck nicely captures the recent state of the world.
Apache2 + mod_wsgi in Daemon mode is probably the most common approach (especially for VPSs), although I know several people who prefer nginx + gunicorn + supervisor. Both are sane and stable options at this point. (The python web frameworks themselves all speak WSGI and there are about seventeen million of 'em to choose from.)
Seems to me that a better title for this article would be "A history of different ways to use Python in the web" rather than "HOWTO Use Python in the web", since most of the article is spent describing old things that should not be used for new projects.
Author here: While I agree that part of this guide are indeed outdated and could be worth an update (which I haven't had the time to since some years) I still think the general basics are useful. I saw many people get into web programming without having a slightest clue how HTTP works, sometimes even after coming from PHP.
Interesting that there's no mention of Tornado [1]. (Disclosure: as a co-author of O'Reilly's Introduction to Tornado, I'm biased in its favor.) I haven't played around with Brubeck [2] yet, but I also hear many great things about it.
Needless to say, there are some great Python web servers and frameworks out there that aren't listed on that page.
I'm also confused. Tornado is definitely a more compelling web framework. Who doesn't want the ability to have tons and tons and tons of long-lived connections?
The article itself says, "While this HOWTO tries to give an overview of Python in the web, it cannot always be as up to date as desired. Web development in Python is rapidly moving forward, so the wiki page on Web Programming [1] may be more in sync with recent development."
So it may not have been the best resource to present on HN in the first place.
Tornado relies on its own HTTP server, but its modules for everything from templating to authentication are loosely coupled, so you can take them or leave them.
To your point, I'd be curious to see a non-Tornado server that is Tornado compatible on the backend. It could be an interesting project. I would counter, however, that any server choice has its own inertia--changing web servers is hardly ever a simple process.
Bottle.py is the simplest way to start playing with web programming in python. Mix it with Jinja and there you have it, good enough for any personal project. Then you make your way up with Flask and Django.
* I wish there was a one-file jinja copycat to make it easier to just drop bottle and jinja and start hacking.
I agree Bottle is simple and has some nice features, but I'm a little wary of the decorator-based "micro"frameworks. In my experience it can lead to strange code structure and it's more difficult to translate into the class-based handlers of larger frameworks.
Moreover, I don't think the barrier of entry to use Tornado, for example, is significantly higher than Bottle, and you can use it for any sized project. I realize that is both a server and framework, but truthfully I guess I'm also wary of WSGI on the whole and wouldn't recommend anyone even start down that rabbit hole in this day and age.
This reminds me, whatever happened to Turbogears? Are many people using it? I never really hear people mention using it compared to Django.
I thought long and hard about the "Should I learn Django or Turbogears" question 3 or four years ago, and went with Django. Back then, Django was not yet the "default" answer.
The TG, Pylons, and Zope guys all joined forces under the Pyramid banner a couple of years ago. There are still people developing in each of those three projects (and I think it's largely still maintained), but the definite trend is to Pyramid itself.
It's a real shame that support for Python Server Pages is as rare as it is in the wild, and that we don't see that kind of capability common in other server side languages. I really think that the ability to mix HTML and server code together painlessly is one of the main advantages that PHP still has today. It's the reason I still use it for new projects even though I dislike almost everything about the language itself.
If I could just say <?coffeescript like that, my programmer-happiness rating would quadruple instantly.
I'd love to see Python Server Pages as well but not implemented anything like it is in PHP. Mixing View and MVC Controller methods/classes in View pages is simply not a sustainable model. Following the PHP example here would seriously taint Python's potential for webapps. Java's JSP, OTOH, is the reference model for that.
One big plus for Python Server Pages is the ability to pre-compile into bytecode. True Python doesn't have near the level of compile-time checking that Java does, but it that could be written into a framework...
I know nothing about python web programming, but I'm hoping to get deep into it very soon. I wanted to point out the framework that I'm planning to use, because I hadn't seen it mentioned in this thread yet.
Why is there a link to python's documentation on HN frontpage? I mean, it's not like it's a new release or, wait for it, was anything new.
Here are some others:
- Python/C API Reference Manual http://docs.python.org/py3k/c-api/
- Higher-order functions and operations on callable objects http://docs.python.org/library/functools.html
- Google http://www.google.com
If it's not useful to post random tutorials, how much less useful is it to post links to documentation for obscure Python versions which hardly anybody uses? Do you even use Python for anything?
Great timing on this. I'm training a very smart & academically accomplished new dev who's spent the last several years pursuing his PhD in CS, but has no idea about web development (I don't consider that a vice).
Fortunately he's one of the awesome, awesome people I can just point at an article and he'll be off and running.
It's both. The server and the framework are to some degree usable independently from one another (via the tornado.wsgi module), but the most interesting features (i.e. all the asynchronous stuff) only work when both are used together.
A couple of other pure-python (I think) HTTP servers that haven't come up in this thread yet are twisted and paster.
Why is something like this being posted? It's been in the docs for ages. Seems like link bait to all the folks drooling over Python lately(of which I am).
I don't know why it was posted, but as a recent convert to Python (and using CherryPy for web development) I'm interested to see what else is out there in the Python ecosystem.
