At 03:22 PM 9/22/2009 +0100, René Dudfield wrote:
On Tue, Sep 22, 2009 at 3:07 PM, P.J. Eby <p...@telecommunity.com> wrote:
> At 11:30 AM 9/22/2009 +0100, Alan Kennedy wrote:
>>
>> I see this as being the same as Graham's suggested approach of a
>> per-server configurable charset, which is then stored in the WSGI
>> dictionary, so that applications that have problems, i.e. that detect
>> mojibake in the unicode SCRIPT_NAME or PATH_INFO, can attempt to undo
>> the faulty decoding by the server.
>
> This puts the burden on the wrong end of the pipe: there are more apps than
> servers and they would *all* have to check this in order to be sane.
>
Except most everyone is using unicode in their apps already through
frameworks.
Great, so only the frameworks need to change, and if we use utf8
surrogateescape, only the applications which need non-utf8 encoding
will need to do anything differently.
That's one factor weighing towards PEP 383, vs. continuing with
latin-1 or going to bytes.
(Frankly, though, I'm getting tired of this handwaving about these
frameworks that use unicode. If they are putting objects of type
'unicode' under WSGI-defined environ keys on Python 2.x, they are
*not WSGI compliant*. And conversely, if they are doing some kind of
conversion already, it's not gonna kill them to do a slightly
different conversion to support the new version of WSGI.)
_______________________________________________
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
