[Web-SIG] Request for Comments on upcoming WSGI Changes
pje at telecommunity.com
Tue Sep 22 07:48:17 CEST 2009
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.)
More information about the Web-SIG