At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
And this doesn't help with Python 3: either we have byte values of SCRIPT_NAME and PATH_INFO in Python 3, or we have text values. I think bytes will be more awkward to port to than text, and inconsistent with other WSGI values.
OTOH, it has the tremendous advantage of pushing the encoding question onto the app (or framework) developer... who's really the only one who can make the right decision for their particular application. And personally, I'd rather have clear boundaries between text and bytes, such that porting (even if tedious or awkward) is *consistent*, and clear as to when you're finished, not, "oh, did I check to make sure I converted SCRIPT_NAME and PATH_INFO... not just in my app code, but in all the library code I call *from* my app?"
IOW, the bytes/string discussion on Python-dev has kind of led me to realize that we might just as well make the *entire* stack bytes (incoming and outgoing headers *and* streams), and rewrite that bit in PEP 333 about using str on "Python 3000" to say we go with bytes on Python 3+ for everything that's a str in today's WSGI.
Or, to put it another way, if I knew then what I know *now*, I think I'd have written the PEP the other way around, such that the use of 'str' in WSGI would be a substitute for the future 'bytes' type, rather than viewing some byte strings as a forward-compatible substitute for Py3K unicode strings.
Of course, this would be a WSGI 2 change, but IMO we're better off making a clean break with backward compatibility here anyway, rather than having conditionals. Also, going with bytes everywhere means we don't have to rename SCRIPT_NAME and PATH_INFO, which in turn avoids deeper rewrites being required in today's apps.
(Hm. Although actually, I suppose we *could* just borrow the time machine and pretend that WSGI called for "byte-strings everywhere" all along...)
_______________________________________________ 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
