can not understate just how well written Tornado is. If you are a web app developer, it is well worth reading the source of the project - you will pick up a lot of tips and tricks on developing quick and scalable apps.
outside of the event loop implementation, the framework components are well written - so tornado is worth checking out even if you are running on a more standard type of web server environment or appengine
my own web app stack contains a number of modules either directly from Tornado or inspired by sections of the project
I found some parts of it to be very poorly written. Like the error handling where it assumes you want to return HTML (remember that Tornado was first written to handle RSS feeds). It also has really poor support for multiprocess mode, where if a child gets killed , the parent does not restart it. Or if the parent is killed, the children may continue running. Also the gzip implementation is broken: if the client mentions gzip even as q=0, Tornado will use it. Just feels like the devs did not not quite pay attention to the details as much as the event loop.
There's never been a real focus on multiprocess. The recommended solution is to run individual instances and load balance them with something like nginx and manage them with supervisord.
Sure the multiprocess stuff is in there, but I honestly wouldn't use it for more than perhaps a dev environment where you want to spool up multiple instances quickly for testing.
Like the error handling where it assumes you want to return HTML (remember that Tornado was first written to handle RSS feeds).
You can override the error handler and return whatever content type you want. Tornado was first written for an HTML site, not RSS feeds. FriendFeed supported an HTML UI before Atom and RSS feeds were added.
really poor support for multiprocess mode
The Tornado people do not recommend using multiprocess mode. They should just delete this code.
Anyone know why they didn't go with Jinja2 for templates? When code is this clean I'm sympathetic towards the "batteries-included" approach, so I'm not criticizing the choice, just wondering if there was a back story, if it got evaluated at all. Same for locale.py vs. PyBabel. The template engine seems far better than Django's at least : )
My guess is that they wanted to go the "self-contained" route as opposed to the "amalgamation of different libraries" approach (a la Pylons/Pyramid). This makes it a lot easier to learn for true beginners since it eliminates the overhead of navigating the documentation of a multitude of different libraries .
Tornado is so flexible, though, that it would be pretty straightforward for you to use whatever templating library floats your boat.
Preference is generally the reason for choosing any framework.
What Tornado provides is a small but well featured framework for building web applications. It's event loop based which allows it to support lots of connections. It also has been built from the ground up with the idea of horizontal scaling of it across multiple load balanced instances so if that's your plan for scaling you know it fits the mold well.
I think that's because Tornado is fantastically simple, and Twisted just isn't.
Tornado is the bare-bones essentials for an async web application server. Twisted is not. You can start with Tornado, then put Django or Twisted on top, but that's optional.
I don't know if that many people inside the python community care either. Twisted is very big, documentation seriously lacking, and a lot of stuff in twisted not that useful if you only care about http. If you care about http, twisted is not that useful either (there is for example no http 1.1 support client-side AFAIK).
It would also have made porting tornado to python 3 a huge effort (given twisted code size).
I am aware of that code: it is undocumented, and does not have support for things as fundamental as keep alive. The underscoring does not inspire confidence either.
You're meant to use the public API twisted.web.client.Agent (which uses _newclient). If anyone's interested in finishing keep-alive support, the ticket is http://twistedmatrix.com/trac/ticket/3420
when Tornado was first released, there was a lot of discussion online on various forums and comment threads about why it wasn't built on top of Twisted, or why it was a complete separate project.
I tend to agree with Brett Taylor in that Twisted was too large a project to suit the goals of Tornado, and that its own divisions within twisted.web were difficult to navigate through
the event handling part of Tornado is less than 100 lines of code and is a lot easier to implement and understand than Twisted, although Twisted also serves a purpose. I like and prefer that Tornado is self-contained and focuses on a single use case (returning JSON in long-polls) and does it well
When the original twisted code was released, I removed 1,297 lines of code to port it to twisted and gained a lot of functionality (tornado has just about no support for doing anything async). Not sure where you get less than 100 lines.
I think it's safe to say a lot of people inside the Python community don't care either. Twisted is incredibly complex and competition in the asynchronous networking space can only be a good thing.
I stand on the other end. The reason why I choose tornado for my startup was because it did not use twisted (too early for twisted in my project). Tornado has a great modular structure so you can use each module on its own. The code is lovely to look at too.
Why would it switch to Twisted if it has always had its own lightweight event loop that's always benchmarked significantly faster? Same goes for fapws3 and gevent.
I can see a lot of reasons to use tornado instead of twisted, but speed is not really one of them. I have not seen a non-trivial benchmark showing one faster than the other (and tornado devs recognize themselves that speed was not that different between the both of them).
There are some philosophical reasons for not using twisted's io loop (for example, because it uses ctypes to interface with epoll et al, or because of the FactoryFactoryFactory Java envy).
Twisted doesn't use ctypes to interface with epoll, it uses a Cython module. Also, the Factory stuff in Twisted usually makes sense, as the alternative is worse (some object in a long-lived closure).
I'm glad to see that, out of all the top-level comments, the ones about Flask and Jinja2 were not highly criticized, but I will never understand the rather massive butthurt that this community seems to feel over Twisted. Is it because people love Tornado, or because people hate Twisted?
Also, as always, since somebody said "Twisted is big," I'd just like to counter: Django is twice as big as Twisted and nobody seems to mind.
outside of the event loop implementation, the framework components are well written - so tornado is worth checking out even if you are running on a more standard type of web server environment or appengine
my own web app stack contains a number of modules either directly from Tornado or inspired by sections of the project