Yes! It's the first thing I looked at when I started on my project. But honestly, I just can't work in Python. I'm not going to bash it, but we just don't jibe. I found EventMachine for Ruby and have a nice pipeline set up, from nginx (server) down to Cramp (framework).
Still, it's not really what I was asking for. I'm looking more for a job messaging architecture, where the client makes a request and the server asynchronously works on it, and sends it down whenever it's finished. Ideally you have one connection that stays constantly open (or you re-open it whenever it closes) that receives the results, and you use the other connection (since the bare minimum for Ajax connections is 2) to make your requests. That requires cooperation on both sides of the gap.
This is generically how long-polling usually works (you have one fast channel for sending messages, then a persistent HTTP connect (either using longpolling or http streaming) to send back responses/results.
However it doesn't seem like you would need that type of architecture unless you need to push data from the server to the client (like email updates or instant messages). There's no real harm in having the first connection open while the server is processing the request.
Still, it's not really what I was asking for. I'm looking more for a job messaging architecture, where the client makes a request and the server asynchronously works on it, and sends it down whenever it's finished. Ideally you have one connection that stays constantly open (or you re-open it whenever it closes) that receives the results, and you use the other connection (since the bare minimum for Ajax connections is 2) to make your requests. That requires cooperation on both sides of the gap.