10 ms·

Tornado 2.1 released

87 points by dtwwtd 15y ago

rjd 15y ago
90% made up my mind to use Tornado for several upcoming projects, would love to hear some comments (good or bad) from anyone thats used it or using it.
- willvarfar 15y ago
  I'm a convert from Twisted. It is simple enough, the code is clear and small enough to dive into if you have any problems, and it works just great.
- peterbe 15y ago
  When speed isn't important and you know you want to use a SQL database; then use Django. For everything else, use Tornado. :)
  - JayInt 15y ago
    when he says Django he really means Flask :-p
- halojones 15y ago
  Easy to get started, easy to deploy, pythonic/magic-free code, responsive maintainer.
- dirtyaura 15y ago
  I've used both Django and Tornado and I vastly prefer Tornado. Some personal experiences: With Django, I specifically don't like ORM and it's template language. Also, I thought the admin interface would reduce the need to write input UIs, but at the end of the day, it's not that suitable for end-user when you have several end-user roles with different access right patterns. If you (read: I) are going to replace Django's template language and leave out ORM and admin interface out of Django, Django doesn't really shine anymore and simpler frameworks like Tornado provide cleaner base for your development.
  - ergo14 15y ago
    Hm, you could take a look at pyramid, if you dont like djangos orm or tempalting it might just be right for you.
- zeemonkee 15y ago
  I've noticed that Tornado comes with its own MySQL wrapper, however I'm concerned it might have blocking issues. Does anyone have experience with using this ? Also, what do people use for form validation with Tornado ?
  - candl 15y ago
    I am curious about what kind of libraries are compatible with Tornado as well. Is there a list that someone maintains? I am specifically interested in things that can bring a bit of the goodies that django provides.
    - peterbe 15y ago
      I've recently been blogging about my tornado-utils library which, for example, brings a email sending library similar to Djangos http://www.peterbe.com/oc-Tornado http://www.peterbe.com/oc-Tornado
  - wisty 15y ago
    The theory is, you shouldn't need async database access. If your database is a bottleneck, you are screwed, regardless of how your app layer is scaling. The main advantage of async is not blocking if you call an external web API.
    - wulczer 15y ago
      That sounds wrong. You need async database access so that while you're waiting for a query to finish, you can still process other requests. Imagine an app that receives an HTTP request every second. One in five of these requests requires making a query that takes 3 seconds to complete. The rest is serviced immediately. You don't want the long request freezing your entire server and preventing the fast requests from being serviced.
      - dchest 15y ago
        From this thread https://groups.google.com/forum/#!topic/python-tornado/mgj18IzasQg https://groups.google.com/forum/#!topic/python-tornado/mgj18... (posting here because Google Groups sometimes require login): We experimented with different async DB approaches, but settled on synchronous at FriendFeed because generally if our DB queries were backlogging our requests, our backends couldn't scale to the load anyway. Things that were slow enough were abstracted to separate backend services which we fetched asynchronously via the async HTTP module. I may open source the async MySQL client I wrote, but I am still skeptical of the long term value given the code complexity it introduces. Bret
- plainOldText 15y ago
  I too am in the Tornado's camp. I love its simplicity. It has decent documentation. And if there's something you don't understand you just peek at the source. I tend to write my code independent of tornado, so if the need arises I can switch to a different framework.
- frio 15y ago
  I wrote a web service in Tornado around a year ago, pre-1.0. It's a very nice, albeit minimal framework. In terms of comparisons to others: * it feels easier to scale up than Flask, but that could be my minimal Flask experience showing. Certainly, it is more performant than basic Flask installations and configurations. * it makes it harder to separate your concerns than, say, Django. I've been working in Django for a long time, and while I have definite issues with the "app"-style packaging (ie. if I add an external forum framework, for instance, I need to munge my "profiles" app to support it), it does feel easier to separate your concerns in Django than in most other frameworks I've used. * it's fast, and reasonably agnostic - the MySQL DB layer, for instance, can be completely eschewed for something else. I imagine they've added a lot to it since then, and the service itself isn't something I've looked at for a while (failed startup idea). But from what I used back then, I'd definitely recommend it.
oxfordus 15y ago
Coming from php(mvc background), the only thing i don't like about tornado is that basically you have a Class per request, currently i'm in a process to refactor this so that: www.site.com/controller/action/params/?vars -> would route to -> class controller(requestHandler): def get_action(self, *params, **vars): #do something self.write(response) def post_action2(self, *params, **vars): #.... and so on ....
- peterbe 15y ago
  I don't get it. Your example is what Tornado looks like:: class LoginHandler(RequestHandler): def get(self): self.render('login.html') def post(self): self.set_secure_cookie(self.get_argument('username')) self.redirect('/') Having one class per URL is very common and perhaps it's more than a decade of Python web programming but I like that. Makes for neat code.
  - ovi256 15y ago
    The one class per action pattern helps with async calls and callbacks. The handler class has methods for each HTTP method plus the callbacks it needs. That would get really messy in a controller-with-multiple-actions pattern as the controller classe now has a lot more methods in a single class: all the HTTP methods it handles plus the callbacks for all of them.
    - oxfordus 15y ago
      i dont agree with you, i would rather have a controller with multiple actions, rather then "controller"/requestHandler per action, because in most cases you want the controller to handle all the actions of a page, rather then one action. Having controller per one action would put overhead on the code lines you write.
- emehrkay 15y ago
  Im a PHP developer who uses Tornado and I recently wrote a PHP micro framework that works like tornado's controllers where rest verbs were the only publicly (uri) accessible methods
slig 15y ago
For a multiplayer, realtime, text-based game, like a quiz, should I dive in nodejs or Tornado? I know Python but never played with server-side javascript before.
- mtogo 15y ago
  It all boils down to what you prefer. They're both relatively mature software packages that are being used by tons in production. Whichever you choose, you may find that http://socket.io/ http://socket.io/ saves you some time by inventing various wheels you may have needed to reinvent (for use with tornado, see the tornadio project).
  - slig 15y ago
    Thank you! Didn't know about tornadio.
LeafStorm 15y ago
Tornado is intriguing, but the main thing I don't like about it is how it reinvents the wheel with a lot of its components. For example: - They created a lot of Web-stuff parsing code themselves, when Werkzeug provides a tested and thorough implementation of a lot of that. (Especially routing, regex-based routing just looks horribly kludgy once you have used werkzeug.routing.) - They created their own template language when they could have used Jinja. (In fact, tornado.template is basically a half-as-powerful copy of Jinja.) - They created their own database access layer when they could have used SQLAlchemy instead. Sometimes I think people take the concept of "minimal dependencies" way too far.
- rgarcia 15y ago
  If you bring in tons of third party code you end up with a mess like Pylons. For people new to a framework, it's a pain to learn that when a problem arises you need to go look up the docs for a separate framework.
  - jamesgeck0 15y ago
    Or you end up with something really solid and enjoyable to work with, like Flask. Which is just a combination of Werkzeug and Jinja with some glue and excellent documentation.
- bdarnell 15y ago
  tornado.database has no real ties to the rest of the system; you can (and I usually do) use SQLAlchemy or another database layer instead. You can also call another template engine if you prefer, but you're sort of stuck with the url routing.
  - crad 15y ago
    I'd be curious as to how many people actually use it. Since it's MySQL specific, it holds little value for anyone not using MySQL ;-)
    - 15y ago
dtwwtd 15y ago
I'm especially looking forward to trying the new interface to Twisted and the gen module. I was about to write some async interfaces to things that are currently not - these new modules look like they'll be helping me out quite a bit.

87 points by dtwwtd 15y ago

rjd 15y ago

90% made up my mind to use Tornado for several upcoming projects, would love to hear some comments (good or bad) from anyone thats used it or using it.

willvarfar 15y ago
I'm a convert from Twisted. It is simple enough, the code is clear and small enough to dive into if you have any problems, and it works just great.
peterbe 15y ago
When speed isn't important and you know you want to use a SQL database; then use Django. For everything else, use Tornado. :)
- JayInt 15y ago
  when he says Django he really means Flask :-p
halojones 15y ago
Easy to get started, easy to deploy, pythonic/magic-free code, responsive maintainer.
dirtyaura 15y ago
I've used both Django and Tornado and I vastly prefer Tornado. Some personal experiences: With Django, I specifically don't like ORM and it's template language. Also, I thought the admin interface would reduce the need to write input UIs, but at the end of the day, it's not that suitable for end-user when you have several end-user roles with different access right patterns. If you (read: I) are going to replace Django's template language and leave out ORM and admin interface out of Django, Django doesn't really shine anymore and simpler frameworks like Tornado provide cleaner base for your development.
- ergo14 15y ago
  Hm, you could take a look at pyramid, if you dont like djangos orm or tempalting it might just be right for you.
zeemonkee 15y ago
I've noticed that Tornado comes with its own MySQL wrapper, however I'm concerned it might have blocking issues. Does anyone have experience with using this ? Also, what do people use for form validation with Tornado ?
- candl 15y ago
  I am curious about what kind of libraries are compatible with Tornado as well. Is there a list that someone maintains? I am specifically interested in things that can bring a bit of the goodies that django provides.
  - peterbe 15y ago
    I've recently been blogging about my tornado-utils library which, for example, brings a email sending library similar to Djangos http://www.peterbe.com/oc-Tornado http://www.peterbe.com/oc-Tornado
- wisty 15y ago
  The theory is, you shouldn't need async database access. If your database is a bottleneck, you are screwed, regardless of how your app layer is scaling. The main advantage of async is not blocking if you call an external web API.
  - wulczer 15y ago
    That sounds wrong. You need async database access so that while you're waiting for a query to finish, you can still process other requests. Imagine an app that receives an HTTP request every second. One in five of these requests requires making a query that takes 3 seconds to complete. The rest is serviced immediately. You don't want the long request freezing your entire server and preventing the fast requests from being serviced.
    - dchest 15y ago
      From this thread https://groups.google.com/forum/#!topic/python-tornado/mgj18IzasQg https://groups.google.com/forum/#!topic/python-tornado/mgj18... (posting here because Google Groups sometimes require login): We experimented with different async DB approaches, but settled on synchronous at FriendFeed because generally if our DB queries were backlogging our requests, our backends couldn't scale to the load anyway. Things that were slow enough were abstracted to separate backend services which we fetched asynchronously via the async HTTP module. I may open source the async MySQL client I wrote, but I am still skeptical of the long term value given the code complexity it introduces. Bret
plainOldText 15y ago
I too am in the Tornado's camp. I love its simplicity. It has decent documentation. And if there's something you don't understand you just peek at the source. I tend to write my code independent of tornado, so if the need arises I can switch to a different framework.
frio 15y ago
I wrote a web service in Tornado around a year ago, pre-1.0. It's a very nice, albeit minimal framework. In terms of comparisons to others: * it feels easier to scale up than Flask, but that could be my minimal Flask experience showing. Certainly, it is more performant than basic Flask installations and configurations. * it makes it harder to separate your concerns than, say, Django. I've been working in Django for a long time, and while I have definite issues with the "app"-style packaging (ie. if I add an external forum framework, for instance, I need to munge my "profiles" app to support it), it does feel easier to separate your concerns in Django than in most other frameworks I've used. * it's fast, and reasonably agnostic - the MySQL DB layer, for instance, can be completely eschewed for something else. I imagine they've added a lot to it since then, and the service itself isn't something I've looked at for a while (failed startup idea). But from what I used back then, I'd definitely recommend it.

oxfordus 15y ago

Coming from php(mvc background), the only thing i don't like about tornado is that basically you have a Class per request, currently i'm in a process to refactor this so that: www.site.com/controller/action/params/?vars -> would route to -> class controller(requestHandler): def get_action(self, *params, **vars): #do something self.write(response) def post_action2(self, *params, **vars): #.... and so on ....

peterbe 15y ago
I don't get it. Your example is what Tornado looks like:: class LoginHandler(RequestHandler): def get(self): self.render('login.html') def post(self): self.set_secure_cookie(self.get_argument('username')) self.redirect('/') Having one class per URL is very common and perhaps it's more than a decade of Python web programming but I like that. Makes for neat code.
- ovi256 15y ago
  The one class per action pattern helps with async calls and callbacks. The handler class has methods for each HTTP method plus the callbacks it needs. That would get really messy in a controller-with-multiple-actions pattern as the controller classe now has a lot more methods in a single class: all the HTTP methods it handles plus the callbacks for all of them.
  - oxfordus 15y ago
    i dont agree with you, i would rather have a controller with multiple actions, rather then "controller"/requestHandler per action, because in most cases you want the controller to handle all the actions of a page, rather then one action. Having controller per one action would put overhead on the code lines you write.
emehrkay 15y ago
Im a PHP developer who uses Tornado and I recently wrote a PHP micro framework that works like tornado's controllers where rest verbs were the only publicly (uri) accessible methods

slig 15y ago

For a multiplayer, realtime, text-based game, like a quiz, should I dive in nodejs or Tornado? I know Python but never played with server-side javascript before.

mtogo 15y ago
It all boils down to what you prefer. They're both relatively mature software packages that are being used by tons in production. Whichever you choose, you may find that http://socket.io/ http://socket.io/ saves you some time by inventing various wheels you may have needed to reinvent (for use with tornado, see the tornadio project).
- slig 15y ago
  Thank you! Didn't know about tornadio.

LeafStorm 15y ago

Tornado is intriguing, but the main thing I don't like about it is how it reinvents the wheel with a lot of its components. For example: - They created a lot of Web-stuff parsing code themselves, when Werkzeug provides a tested and thorough implementation of a lot of that. (Especially routing, regex-based routing just looks horribly kludgy once you have used werkzeug.routing.) - They created their own template language when they could have used Jinja. (In fact, tornado.template is basically a half-as-powerful copy of Jinja.) - They created their own database access layer when they could have used SQLAlchemy instead. Sometimes I think people take the concept of "minimal dependencies" way too far.

rgarcia 15y ago
If you bring in tons of third party code you end up with a mess like Pylons. For people new to a framework, it's a pain to learn that when a problem arises you need to go look up the docs for a separate framework.
- jamesgeck0 15y ago
  Or you end up with something really solid and enjoyable to work with, like Flask. Which is just a combination of Werkzeug and Jinja with some glue and excellent documentation.
bdarnell 15y ago
tornado.database has no real ties to the rest of the system; you can (and I usually do) use SQLAlchemy or another database layer instead. You can also call another template engine if you prefer, but you're sort of stuck with the url routing.
- crad 15y ago
  I'd be curious as to how many people actually use it. Since it's MySQL specific, it holds little value for anyone not using MySQL ;-)
  - 15y ago

dtwwtd 15y ago

I'm especially looking forward to trying the new interface to Twisted and the gen module. I was about to write some async interfaces to things that are currently not - these new modules look like they'll be helping me out quite a bit.