Regarding design choices, I think Brubeck and Diesel are indeed the future. They don't rely on the broken ideas found in WSGI and they don't attempt to bolt on concurrency. Both are designed around an async / nonblocking system that removes the horrible callbacks found in Node.js, Twisted, Tornado and even provide a system for converting your blocking calls into nonblocking calls.

On top of that, the performance of these two, by being based in gevent, blows the other systems out of the water. Tornado and Twisted are both slower due to so much of the core loop being written in Python instead of C. Here is a simple hello world comparison of Brubeck vs. Tornado: https://gist.github.com/2252671 - What we see is that at it's base level, meaning there's no I/O or CPU bound tasks, gevent is straight-up much faster.

Regarding features, Brubeck can already generate a REST API for you, provides auth hooks, has oauth plugins, supports the template systems you care about, works great with mongo, riak, redis, postgres, mysql, all with nonblocking support, and it even comes witha modeling layer that won't force badly generated queries on you, aka databaseless schemas.

(As said in my other comment, I am biased due to being on Brubeck's core team)

Using flask with websockets via gevent is pretty easy, I imagine this would also be true for other frameworks

You may be referring to this thread: http://news.ycombinator.com/item?id=3766137

Personally, I am working in Clojure these days, in part because of this and its concurrency model.

See the Clojure Aleph library for WebSockets (https://www.google.com/search?hl=en&safe=off&pws=0&#...).

Pyramid + gevent-socketio is the way to go for real-time web applications using python.

Brubeck has experimental WebSockets support coming up soon. The basic idea is that all of the socket proxying takes place in Mongrel2 and Brubeck handlers simply process messages from the socket.

Brubeck, in this design, is asynchronous and full duplex, just like websockets themselves. The other models I've seen seem to require hooking your webframework up directly to the servers, without any socket proxying support. That might be useful for small installations, but it is a core design goal of Brubeck to make life easy as you scale up. Having Mongrel2 proxy the connections is part of how we do that.

(As the original author of Brubeck, I am biased)

Using web.py and loving it! http://webpy.org/