On Tue, Aug 4, 2009 at 11:05 AM, P.J. Eby<p...@telecommunity.com> wrote: > 1. Force all encodings to be explicit, and
This can be handled without forcing application authors to work with bytestrings (or forcing them to remember to coerce to bytestrings before returning responses). > 2. Ensure WSGI<->HTTP equivalence (i.e., WSGI==HTTP encoded in Python > objects) TBH, WSGI doesn't expose enough of HTTP's functionality to convince me that this is a good argument. When I can use advanced HTTP features (chunked transfer and friends) from a WSGI app, maybe I'll feel differently. > Please remember that WSGI is not primarily intended to provide application > developers with a convenient API; its first and most important job is to > ship the data around without mangling it in the process. Which it should try very hard to do without forcing *in*convenient APIs onto developers. > So I would ask, what is the practical use case for having the server decode > bytes into strings, instead of leaving them as bytes? Well, Django (for one example) already does some gymnastics to ensure that character encoding issues are kept at the request/response boundary, largely because it's an utter pain for an application developer to have an API dump a bunch of bytestrings in your lap and say "here, *you* figure it out". I suspect we're going to keep on doing that, since it's a big win in terms of usability for application developers (who end up having to deal with only a drastically-reduced subset of character-encoding problems). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." _______________________________________________ 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
