On Wed, Apr 1, 2009 at 3:37 PM, P.J. Eby <p...@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/) _______________________________________________ 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