2009/8/7 Damjan <[email protected]>:
>
>> Not very well.
>>
>> We are having another argument about WSGI specification and Python 3.0
>> at the moment on Python WEB-SIG list. The discussion seems to have
>> exploded over night and have about 30 messages to read about it yet.
>>
>> If some sort of resolution isn't reached this time I am going to give
>> up and simply not support Python 3.0.
>
> I'd say that requiring UTF-8 (on the client side) and making most of
> WSGI unicode is the better option. Maybe, as P.J.E says, that way WSGI
> will loose some of it's idempotency with HTTP, but who cares... WSGI
> is about Python applications!
>
> And if a request comes that can't be decoded as UTF-8 .. then a "400
> Bad Request" error should be thrown.
>
>
> The other option, will mean that every web framework and every WSGI
> middleware, and every programmer will have to reimplement the
> character  conversion heuristics (and probably do it wrong).
>
>
> I don't see any problems with declaring an UTF-8 constraing for data
> coming from the HTTP side. Less (unneeded) choice for programmers,
> middleware and frameworks is good!

The issue raised over UTF-8 are significant enough to kill that idea.
At least I can't see getting any agreement on it to make it
worthwhile.

What I would like to know is if rack and jack only use UTF-8 as stated
by one person, what do they do to handle the problems people are
raising as a reason not to do it in WSGI.

Graham

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to