[Web-SIG] WSGI for Python 3
graham.dumpleton at gmail.com
Wed Jul 14 07:22:49 CEST 2010
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:
>> 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
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.
More information about the Web-SIG