Comments on: Tornado’s Big Feature is Not ‘Async’

By: whardier

whardier — Thu, 26 Jan 2012 21:20:45 +0000

I honestly like the simplicity of smaller frameworks as long as there is a method for dealing with thread safe database calls. I spent far too many hours dealing with how Django preferred to, even after lazy loading, deal with queries and joins. I was impressed by how the ORM worked but above and beyond slow unscalable queries mapping/pickling/reclassing/etcing the data even if I was using MongoDB or something similar eventually became a huge bottleneck.

So I see a lot of benefit from the async side of tornado.. but the biggest feature is simple and direct access for people that are beyond the prototype stage and don’t need the handy helpers but still want a python oriented solution that has enough basic modules to be useful.

I’m using tornado for sockets, for redis access, for mongodb and I’m using it to create tools that compliment the front end.. so I’m lovin it. I hope you’re still on the boat.

By: Marrying Boto to Tornado: Greenlets bring them together | Josh Haas's Web Log

Sun, 19 Jun 2011 23:42:36 +0000

[...] I don’t really use Tornado for its non-blocky awesomeness, I use it for the get out of deployment-hell free card. But, if I’m gonna add it to my tech stack, I do want my money’s worth — [...]

By: Mark

Mark — Wed, 08 Jun 2011 15:58:14 +0000

With Tornado’s fork Anzu you can do this:

@location(‘/login’)
class LoginHandler(BaseHandler):
# …

@error_handler(get)
@validate(validators={‘email’: validators.Email(not_empty=True, min=7, max=64),
‘password’: validators.UnicodeString(not_empty=True, min=6, max=32, strip=False)})
def post(self):
# …

By: Robert Mela

Robert Mela — Wed, 02 Mar 2011 16:06:10 +0000

mod_wsgi’s been great for us and no problem at all to configure. We’ve used it with standalone wsgi, with Django, and with Flask.

The problems you describe seem to be related to getting Python path set up. This to me is a generic Python issue, not specific to mod_wsgi.

The way we do it for our apps is pretty simple — we include our wsgi files in the app repository, typically under the root of the application.

So, for a simple WSGI or Flask app -

myapp/__init__.py
myapp/myscript.py
myapp/wsgifiles/myapp.wsgi

Then, in myapp.wsgi –

import sys,os

# Append parent directory of this wsgi file to python path
pathElements = os.path.dirname(__file__).split(‘/’)[0:-1]
sys.path.append(“/%s” % “/”.join(pathElements) )

# Now that the path is set, load the symbol for the wsgi application

from myapp import foobar as application # where foobar is a wsgi application

There — now that isn’t so hard…. tho Django IIRC requires the parent of the application directory be in the path — and that IIRC was a minor headache.

By: Glyph Lefkowitz

Glyph Lefkowitz — Wed, 07 Apr 2010 22:21:00 +0000

If your concern is deployment, why not just deploy Django with Twisted? It only takes a few seconds to get started:

http://blog.dreid.org/2009/03/twisted-django-it-wont-burn-down-your.html

if you want a slightly more robust deployment setup, you can also check this out:

http://clemesha.org/blog/2009/apr/23/Django-on-Twisted-using-latest-twisted-web-wsgi/