On Sun, Sep 20, 2009 at 8:06 AM, Armin Ronacher <armin.ronac...@active-4.com> wrote: > Thanks to Graham Dumpleton and Robert Brewer there is some serious > progress on WSGI currently. I proposed a roadmap with some PEP changes > now that need some input. > > Summary: > > WSGI 1.0 stays the same as PEP 0333 currently is > WSGI 1.1 becomes what Ian and I added to PEP 0333 > WSGI 2.0 becomes a unicode powered version of WSGI 1.1 > WSGI 3.0 becomes WSGI 2.0 just without start_response > > WSGI 1.0 and 1.1 are byte based and nearly impossible to use on Python > 3 because of changes in the standard library that no longer work with > a byte-only approach.
1.1 I think of as an errata on 1.0, so... simple enough. I was skeptical about a unicode version of WSGI, but I think I'm okay with it now. For people who use UTF-8-only it should be fairly simple and easy; for people who want to deal with other encodings, backward compatible URLs, or other weirdness I think surrogateescape can resolve the small handful of problems. Maybe an option to use latin1 (at the server level) would do the same for Python 2, as a deployment option for people who are dealing with these tricky issues. Which is kind of lame, but it means everything is still *possible*, and the use cases are somewhat obscure. Especially because QUERY_STRING and wsgi.input remain bytes. (Well, I guess the other case would be someone reading a cookie set by an application they do not control, and set in a crazy way... but anyway, there's a handful of use cases where things get tricky, but we can kind of punt, or try to implement the necessary transcoding routines before the spec is final.) I'm very much opposed to a second "raw" version of the request, as I do not like redundancy. With respect to 3.0/start_response, I'd rather we just do both at once, so there's not so many versions of WSGI to worry about. Also it doesn't feel like a very difficult change to make. The only other major issue is wsgi.input, which is a quite awkward interface to the request body. But I think resolving that is harder than start_response, in particular because there's no clear solution. Maybe at least switching to a file interface would be better. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com