[Web-SIG] Request for Comments on upcoming WSGI Changes

[P.J. Eby]

At 02:30 PM 9/22/2009 +1000, Graham Dumpleton wrote:
>Someone did say something about being able to half make it work on
>Python 2.X. Can someone properly provide example code for Python 2.X.

The issue is that error handlers on encode are only allowed to 
provide substitute unicode characters, not substitute bytes.  That's 
why it can only "half work" on 2.x.


>If we want uniformity in how interface works on Python 2.X and 3.X,
>they we have to be able to use same method without tricks. This is why
>wsgi.uri_encoding at the moment seems better, as not reliant on a
>feature only in Python 3.1+.

If we want uniformity in the interface, then we should continue using 
latin-1, which already works today.  Yes, it sucks, but it sucks *uniformly*.

There really isn't going to be a solution that satisfies *all* of the 
criteria we're batting around, for *all* the users.  What's happening 
is that the principals are focused on different scenarios, where all 
their criteria can be met at the expense of others'.

I'm tending to flip-flop a bit myself, because my goal is that 
*nobody* "wins", in the sense of having an advantaged framework, 
server, programming paradigm, etc. relative to others.  And that 
means there are more ways of doing it that would be acceptable to 
me.  For example, all bytes, all latin-1, all surrogateescape...  I 
don't care all that terribly much between them, I just want it to be 
uniform for everybody using/implementing the spec.  (And that also 
means I want it uniform across all keys, not just the URI ones; I 
don't want to have to remember which ones are special cases.)

If some people need to do more code because of their particular codec 
requirements, that's okay by me, as long as it's *unconditional* code 
that doesn't depend on some sort of configuration rigamarole.  That 
makes the spec brittle, because nobody's going to test their edge 
cases, and then the consumers of the code are gonna be the ones 
getting screwed over.

Frankly, 90% of WSGI code written will never even check the 
wsgi.version number, so why would we think anybody's going to 
actually check wsgi.url_encoding?  That's just building in the suck 
from day one.  No offense intended to the proposer of it; it's a fine 
solution for a single project's API, but it's just not going to scale.

We already know this, because most WSGI code written is not to 
spec.  The ones of us here in the room talking about this are *not* 
good examples of average WSGI programmers, because (hopefully) we've 
all at least studied the spec and endeavored to fully grok and 
conform to it.  (Hell, an unfortunately large number of people think 
you're supposed to use write() or yield to send *individual lines* of text.)

So you better believe that everybody else is going to copy the worst 
available examples of other people's WSGI code and ignore any 
documentation associated with it...  and then they will expect it to 
work on your server.  ;-)

Thus, our target audience is people who will rotely copy...  which 
means we need an API they can either copy by rote, or know is wrong 
when they get an error message.  Conditionals and error handling are 
too much to ask of them, as is remembering different rules for 
different environ keys that all kind of look alike.  (There's a 
reason we required ALL_CAPS keys to be the same type in the first spec.)