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.
Whoops.
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.
Comments
11 spam comments omitted.
I am no longer accepting new comments.
Jonathan LaCour
#2205, 2008-03-03T17:50:19Z
See, as I have gone forward, I have become even more convinced that WSGI is extremely important. Even after reading (and understanding) Philip and Ben's posts on the subject. You say that the opinion is "spectacularly wrong" but give no actual reasons, apart from linking to other people's thoughts, why this is the case. You might need to expand a bit, in order to enlighten us all regarding your thought process.
Philip's point is that WSGI by itself, isn't enough. Its not a good place to define your API, rather it is a common base to build on top of. A consistent language you can speak in the "plumbing" of your application. A good example of this is "beaker" which is the session/cache system used by Pylons. It has a nice API where you deal directly with session/cache objects, rather than the WSGI environ itself, but is based upon WSGI.
The funny thing is, the deeper and further along I get into my applications, the less I use the features of the framework itself, and the more I end up rolling my own to suit my personal needs. If WSGI is at the core of my framework, doing this is quite easy, and gives me a consistent language to speak across the stack. I can reliably understand where in the WSGI stack I need to hook in, what pieces of information I need to access in the environment, and even provide a nice clean API for other parts of my application to use this information.
Yes, WSGI is an interface, but it doesn't just have to be something that you deal with when you connect your application to a WSGI server. It can be a much more integral and useful part of your application.