On 14 July 2010 15:18, Ian Bicking <i...@colorstudy.com> wrote: > On Wed, Jul 14, 2010 at 12:04 AM, 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. > > My intuition is that won't be that bad. At least compared to any library > that is dealing with str/unicode porting issues; which aren't easy, but so > it goes. > >> >> > * 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. > > That's fine with me too. > >> >> > 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. > > Thanks, I was looking for that. I remember the primary objection to a > SCRIPT_NAME/PATH_INFO change was from you. Do you still feel that way?
I accept that access to the raw information may help for people who want access to repeating slashes or other encoded information that an underlying web server may alter, but I cant remember in what way this helps with the Python 3 issues. That is why I just made the comment in other email. Perhaps you can cover how this helps with Python 3. > I generally agree with your interpretation, except I would want to strictly > disallow unicode (Python 3 str) from response bodies. Latin1/ISO-8859-1 is > an okay encoding for headers and status and raw SCRIPT_NAME/PATH_INFO, but > for bodies it doesn't have any particular validity. > > I forgot to mention the response, which you cover; I guess I'm okay with > being lenient on types there (allowing both bytes and str in Python 3)... > though I'm not really that happy with it. I'd rather just keep it symmetric > with the request, requiring native strings everywhere. The reason for allowing it in the response content was so the canonical WSGI hello world still work unmodified. 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
