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.)
_______________________________________________ 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
