For a very long time, I considered the lack of WSGI in Django's architecture to be one of the biggest things - no, the single largest thing - keeping me from embracing it completely. As it turns out, that opinion isn't just wrong, it's spectacularly wrong.
While I was always aware that PEP 333 was the Web Server Gateway Interface specification, I somehow got the false impression that this means that the web application framework, in some fuzzy fashion I didn't really think through, also needed to use WSGI. I don't think I'm the only one. In his TurboGears advocacy post, Jonathan LaCouer said:
But, the thing that truly irks me with Django is its lack of WSGI at the core. Sure, it has support for WSGI, but it feels bolted on, and isn't a major aspect of its design or implementation as far as I can tell.
That, too, was my opinion. I'd like to amend that, though: Philip Eby (who wrote PEP333) cleared it up for me in a post that I managed to miss until a couple of weeks ago, and Ben Bangert also grokked this distinction long before I did.
In some ways, Jonathan is right: WSGI is bolted on to Django. It's, well, an interface. It's one possible entry point, among others, but the internal architecture need not stay WSGI compatible at all points.
That's not to say everything's sunshine and butterflies in the Django/WSGI world. There's still issue 285, which is already 2 years old. But compared to the rather larger (non-)issue of Django's internal HttpRequest and HttpResponse implementation details, that's something that can be convincingly fixed.
Which, all told, is a much better situation than the alternative.