[Web-SIG] WSGI for Python 3
pje at telecommunity.com
Fri Jul 16 20:40:10 CEST 2010
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"
More information about the Web-SIG