[Web-SIG] WSGI and start_response

Graham Dumpleton graham.dumpleton at gmail.com
Wed Apr 14 03:57:35 CEST 2010


On 13 April 2010 23:55, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> On Tue, Apr 13, 2010 at 14:46, Graham Dumpleton
> <graham.dumpleton at gmail.com> wrote:
>> The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.
>>
>> And when I say 'last attempt', yes there have been people who have
>> stepped up to try and get this to happen in the past. I think you
>> would be the 3rd time, excluding me in general having tried to push it
>> in the past and also given up.
>>
>> You really should perhaps look back through the archive of WEB-SIG
>> posts on Google Groups to understand the history and how this always
>> seems to just go around in circles. :-)
>
> I've been on Web-SIG for quite a while now, exactly to keep track of
> these issues.
>
> Since there doesn't seem to be much traction, I figured it would be
> time to just get a new PEP together. To limit the amount of work, I'd
> go in the direction of having a single WSGI 2.0 PEP

Limiting your work by going to WSGI 2.0 and dropping start_response()
potentially causes more work for anyone implementing WSGI.

This is because if no official statement about Python 3.X is made
about WSGI 1.0 (with start_response()), and the only option is WSGI
2.0 (without start_response()), people are likely going to be less
inclined to move to Python 3.X for WSGI because to do so means
potentially more drastic changes to their code.

People talk about WSGI 2.0 -> WSGI 1.0 adapters, but if WSGI 1.0 on
Python 3.X is formalised, you can do that.

> incorporating your
> suggestions (maybe minus the number 3), everything required for Python
> 3 (as outlined by your wiki page).

The whole point of not doing (3) in WSGI 1.1 was that it was seen that
it could only be done, if it were to be done, at a point where the API
was broken anyway, ie., when start_response() was dropped in WSGI 2.0.
So, it shouldn't be ruled out in WSGI 2.0 as a possible change. If you
do, then it likely would never be able to be incorporated. So WSGI 2.0
is the only chance to clean that up.

> The idea is that, as soon as there is a draft PEP, we can circulate it
> on Web-SIG for a little bit before bringing it to python-dev. No
> single person should really be able to block all this.
>
> I'll try to write something up that incorporates all of your notes.

Graham


More information about the Web-SIG mailing list