I would also consider the flexibility and re-usability of middleware to be a big assist too since it will allow a variety of talented developers using multiple frameworks ways to consolidate efforts.
Some examples of current middleware in Paste: - Eval Exception (that awesome AJAX-based interactive Python traceback explorer) - HTTPExceptions (a standard 404/500/etc HTTP catcher) - Auth functions (Secure Cookies, OpenID, CAS, Digest, Basic) Obviously the middleware just takes part of one side of most the problems, but it does push re-usable portions into a place where we can all actually re-use them. Being able to attach small WSGI apps, plug-and-play style, also is rather powerful. If you take a look at the end of the middleware file I use: http://pylons.groovie.org/svn/trunk/pylons/templates/paster_template/+package+/config/middleware.py_tmpl With the knowledge that the Cascade app tries each app, and moves on if it gets a 404, its pretty obvious how you could extend your app to support multiple static doc roots (I hope). A basic amount of working knowledge immediately becomes quite powerful. Several parts of TurboGears would work great as smaller WSGI apps used by default on a new TG project. It's also be easy to toggle them on/off. Ie, turn on the Toolbox during dev mode, but off during production. Or even package Catwalk as a small Paste compatible app, and anyone working on a SQLObject-based project can toss up a nice Catwalk explorer just by pointing a conf file to their models file... The possibilities are powerful, extensible, and quickly approaching viability. The middleware file I use could be used almost directly with TurboGears by replacing the pylons.make_app thing, with the command needed to create a CherryPy WSGI app. This isn't pie-in-the-sky stuff, its very close at hand, especially with the CherryPy patch. Given the inevitability that different frameworks will appeal to different people, being able to unite on hard problems wherever possible is a big win in my book.
