[Web-SIG] WSGI 2

[James Bennett]

On Tue, Aug 4, 2009 at 11:05 AM, P.J. Eby<pje at 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."