PyCon 2009 and Looking to WSGI 2.0

By Eric Larson
March 30, 2009 | Comments: 1

I just returned from PyCon in Chicago. During the conference open spaces there was an open space discussing potential changes for WSGI. The three basic ideas were:

  1. Return a tuple with the status, headers, and response instead using the start response function.
  2. Use unicode (utf-8) by default. This mainly effects the encoding of headers and values in the environ dict.
  3. Make the WSGI input an interable instead of a file like object.

The first was pretty well excepted and people discussed making the wrapper. Since I had a moment on the plane ride home, I went ahead and wrote up some simple middleware and helpers to translate the current WSGI API to this new one. I call it Pack as Mark Ramm mentioned the idea came from Rack and Jack (the Ruby and Javascript WSGI-like implementations). You can find the source on Bitbucket.

The unicode issue seemed to eventually be loosely agreed upon in that the server would say what encoding it uses and the application can then override that if necessary.

The change of WSGI input was a little more complicated. To those that don't know, the WSGI input is effectively like the request body. In the world of RESTful services there is the chance this could be a very large file, so it is common for middleware to stream the content. The issue with it being a file is that middleware can effectively destroy it by simply using it. This is why there was an idea to change it to an iterator of some sort in order to allow middleware to safely use the value in the environ dict without effecting other aspects of the application.

If you are interested in following along with the conversation, check out the Python Web SIG mailing list.

You might also be interested in:

1 Comment

I read this and can't get past returning a tuple of (tatus, headers, response). It just makes me so happy. That's all I want in life. WSGI 2, liberate us from start_response() !

It's funny because PHP apps suffer from the same problem that the start_response() paradigm suffers from. You will get an error like "headers already sent" if other components call header(key,val). Python should be better than PHP, right?! It is a pain to work around this in WSGI 1

News Topics

Recommended for You

Got a Question?