[Web-SIG] WSGI for Python 3

[Graham Dumpleton]

On 14 July 2010 15:18, Ian Bicking <ianb at colorstudy.com> wrote:
> On Wed, Jul 14, 2010 at 12:04 AM, Graham Dumpleton
> <graham.dumpleton at gmail.com> wrote:
>>
>> On 14 July 2010 14:43, Ian Bicking <ianb at 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