[Web-SIG] Python 3.0 and WSGI 1.0.

[Guido van Rossum]

On Wed, Apr 1, 2009 at 3:37 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 01:09 PM 4/1/2009 -0700, Guido van Rossum wrote:
>>
>> Well you could make the bytes versions available under different keys.
>> I think you do something a bit similar this in webob, e.g. req.params
>> vs. req.str_params. (Perhaps you could have QUERY_STRING and
>> QUERY_BYTES.) The decode() call used to create the text strings could
>> use 'replace' as the error handler and the app could check for the
>> presence of the replacement character ('\ufffd') in the string to see
>> if there was a problem; or it could just work with the string
>> containing that character and report the user some kind of 40x or 50x
>> error. Frameworks (like webob) would of course do the right thing and
>> look for QUERY_BYTES before QUERY_STRING. QUERY_BYTES should probably
>> be optional.
>
> The big problem I see with this approach is that any middleware that
> operates on these environment keys would have to be changed.
>
> I think perhaps the problem here is the assumption that the environ
> dictionary has to be a straight-up copy of os.environ, when it can be
> whatever we want it to be.  If wsgiref or other CGI->WSGI gateways have to
> change to get the environ set up correctly, this is less of a problem than
> forcing everybody to rewrite their middleware and apps.

Well I would assume that changing the type of these variables to bytes
would *also* cause problems for a lot of middleware.

The proposal that the bytes values should be in the 'wsgi.*' namespace
would work for me too.

Note that os.environ already has some not-entirely-solved problems
with encodings, which we currently try to pretend don't exist...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)