Sure, there are lots of potential nitpicks that you can have with WSGI and WSGI middleware — mostly because the CGI spec on which WSGI is based is getting a bit long in the tooth — but I think those who get worked up about that kind of thing are missing the point.
WSGI provides a known, standard, working way to create reusable components of functionality which are coupled only to a published specification, not to your code. It’s the same reason that HTTP was so successful in the first place, you can build stuff without knowing exactly how it will be used later.
A perfect example of this is the new repoze.squeeze middleware that was released a couple of days ago.
Sure you could do this same thing with Django middleware, but if you use WSGI then Zope, Django, TurboGears, Plone, and any other WSGI compliant app can just use it without having to worry about this stuff inside the app itself.
BTW, they also released repoze.bitbit
which automatically re-sizes images before sending them out. When coupled with a good caching proxy server this makes it very easy to let people link to any-sized version of any of the images in your library. While i don’t think it’s as widely useful as repoze.squeeze, it too provides an example of something that can just sit there transparently helping you, and it exemplifies a kind of very loose coupling that is a mark of “true middleware.”
There’s another kind of middleware which does stuff that’s “required” for your app to work properly, and I agree that it’s probably best to call this something else, since it’s not transparent, but I think it too has a wide variety of uses, but that’s a blog post for another day.