On 14 July 2010 15:04, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > On 14 July 2010 14:43, Ian Bicking <i...@colorstudy.com> wrote: >> So... there's been some discussion of WSGI on Python 3 lately. I'm not >> feeling as pessimistic as some people, I feel like we were close but just >> didn't *quite* get there. > > What I took from the discussion wasn't that one couldn't specify a > WSGI interface, and as you say we more or less have one now, the issue > is more about how practical that is from a usability perspective for > those who have to code stuff on top. > > The concern seems to be that although it may be easy to work with the > specification for those who at the lowest layer immediately wrap it in > a higher level abstraction that normalises stuff into something that > is then used consistently in that way, for those who use lower level > raw WSGI right through the stack, especially in the context of > stackable WSGI middleware, that repetitive task of having to deal with > the byte/unicode issues at every point it just a big PITA. > > That said, my job in writing the WSGI adapter is really easy as I > don't have to worry about these issues. This is why I don't seem to > really appreciate the concerns people are expressing. The above is how > I read things though. > >> Here's my thoughts: >> >> * Everyone agrees keys in the environ should be native strings >> * Bodies should stay bytes >> * Can we make all "standard" values that are str on Python 2, str on Python >> 3 with a Latin1 encoding? This is basically what wsgiref did. This means >> HTTP_*, SERVER_NAME, etc. Everything CGIish, and everything with an >> all-caps key. There's only a couple tricky keys: SCRIPT_NAME, PATH_INFO, >> and HTTP_COOKIE. >> * I propose we let libraries handle HTTP_COOKIE however they want; don't >> bother transcoding *into* the environ, just do so when you parse the cookie >> (if you so choose). Happy developers will just urlencode all their cookie >> values to keep their cookies ASCII-clean. Unhappy developers who have to >> handle legacy cookies will just run environ['HTTP_COOKIE'].decode('latin1') >> and then do whatever sad magic they are forced to do. >> * I (re)propose we eliminate SCRIPT_NAME and PATH_INFO and replace them >> exclusively with encoded versions (that represent the original request >> URI). We use Latin1 encoding, but it should be ASCII anyway, like most of >> the headers.
BTW, it should be highlighted whether this change is relevant to Python 3 but like some of the other things you relegated as out of scope, purely a wish list item. Graham >> * I'm terrible at naming, but let's say these new values are RAW_SCRIPT_NAME >> and RAW_PATH_INFO. > > My prior suggestion on that since upper case keys for now effectively > derive from CGI, was to make them wsgi.script_name and wsgi.path_info. > Ie., push them into the wsgi namespace. > >> Does this solve everything? There's broken stuff in the stdlib, but we >> shouldn't bother ourselves with that -- if we need working code we should >> just write it and ignore the stdlib or submit our stuff as patches to the >> stdlib. > > The quick summary of what I suggest before is at: > > http://code.google.com/p/modwsgi/wiki/SupportForPython3X > > I believe the only difference I see is the raw SCRIPT_NAME and > PATH_INFO, which got discussed to death previously with no consensus. > >> Some environments will have a hard time constructing RAW_SCRIPT_NAME and >> RAW_PATH_INFO, but in my opinion they can just encode SCRIPT_NAME and >> PATH_INFO and be done with it; it's not as accurate, but it's no less >> accurate than what we have now. >> >> Actual transcoding in the environ is not supported or encouraged in this >> scheme. If you want to adjust an encoding you should do it in your >> application/library code. >> >> There's some other topics, like chunked responses, unknown request body >> lengths, start_response, and maybe some other things, but these aren't >> Python 3 issues, they are just... generic issues. app_iter.close() might be >> worth thinking about given new iterator semantics introduced since WSGI was >> written. > > Graham > _______________________________________________ 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