[Web-SIG] WSGI for Python 3
ianb at colorstudy.com
Wed Jul 14 07:18:54 CEST 2010
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
> > * I'm terrible at naming, but let's say these new values are
> > 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Web-SIG