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 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. -- Ian Bicking | http://blog.ianbicking.org
_______________________________________________ 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
