[Web-SIG] PEP 0333 and PEP XXXX Updated

Graham Dumpleton graham.dumpleton at gmail.com
Mon Sep 21 12:42:42 CEST 2009


2009/9/21 René Dudfield <renesd at gmail.com>:
> On Mon, Sep 21, 2009 at 2:46 AM, Robert Brewer <fumanchu at aminus.org> wrote:
> ...
>> I want something in between so I don't have to wait months or years for
>> WSGI 2. I want to ship a version of CherryPy with Python 3 support last
>> week.
>
> +1 for wsgi 1.1 *very soon* using the "wsgi.url_encoding" idea Graham
> made for unicode.

At this point I would suggest that having 'wsgi.uri_encoding' in WSGI
2.0, as Armin describes, is probably better since the unicode hop is
more than what a minor version change really should entail. Having
definition #3 as WSGI 1.0 for Python 3.X is also probably just a waste
of time and will just confuse. As it was stated by someone, too many
versions of things isn't good and WSGI 1.0 as per definition #3 for
Python 3.X is one such thing which is unnecessary.

> With the next WSGI afterwards being an 'anything goes' spec, which
> addresses all other issues and can come later (including async, using
> buffers, and every other idea people can come up with).

There are no other issues except for dropping start_response(), and
async doesn't belong in WSGI. If you want async, then come up with a
separate standard. You may well manage some overlap which allows
sharing of some small subset of components, but in the main, a
component which is blocking will not work on async and a component
that uses async features isn't going to work on blocking. Why then
would you make a specification overly complicated by trying to handle
both when there is little if any mutual benefit.

It is also likely that it is going to be hard enough to get people to
switch over, so the last thing you want is drastic change. As Armin
also points out, one doesn't know where web server technology is
going. As such, better off only going as far as WSGI 3.0 as described
and then let things settle down. Once that is all firmly in place and
working well, than can step back and look at where web serving
technology has gone in the mean time.

Graham


More information about the Web-SIG mailing list