[Web-SIG] PEP 0333 and PEP XXXX Updated

[Robert Brewer]

Graham Dumpleton wrote:
> Looking at the bigger picture, there are three overall goals that I
> can see that we would want to address.
> 
> 1. Clarifications and corrections to existing WSGI for Python 2.X to
> allow readline() with size hint, mandatory end of stream sentinel for
> wsgi.input, support for chunked request content and rules on amount of
> data that should be returned by WSGI applications and how much data
> wsg.file_wrapper should send back from a file when Content-Length is
> defined. These were the points (11) to (16) that I tacked onto my
> definition #4, in my blog post. They are applicable though to any
> update to WSGI for any version of Python.
> 
> 2. Come up with a version of WSGI for Python 3.X. The whole bytes
> versus unicode discussion.
> 
> 3. Drop the start_response() function and ability to use its write()
> function returned as result. What people have been calling WSGI 2.0.

My goals, in priority order, for the next version(s) of WSGI:

1. Full unicode (not just x00-xFF) in Python 3 for the environ keys and
most values (not wsgi.input, for example).
2. Points 11-16 as you described.
3. The ability to upgrade a WSGI1.0/CPython2.x application to CPython3
using 2to3, minimizing ancillary changes, even if that means requiring
an upgrade to the WSGI version in the process.
4. Minimize the special cases in any new spec. Note this is at the
lowest priority.

> To go along with that, there are a couple major questions I think
> needs to be answered and this will dictate to a degree what any
> roadmap will be.
> 
> The first question is, should Python 2.X forever be bytes everywhere,
> or if we start introducing unicode into parts of the definition for
> Python 3.X, should those versions of the WSGI specification map those
> unicode parts back in to the Python 2.X of an equivalent version of
> the specification?

CherryPy 3.x on Python 2.x will always use bytes everywhere, as we have
always done. So I understand completely if Django, Pylons, etc have
"always used" unicode and want to keep doing that. If y'all decide to
make a version of WSGI which requires unicode because you think it's
easier or more popular, no problem--CherryPy 3.2+ on Python 2 will just
convert back to bytes before handing off that data to CherryPy apps.
This is one reason why a new "wsgi.url_encoding" entry would be required
if SCRIPT_NAME/PATH_INFO/QUERY_STRING become unicode.

> In my definitions I introduced 'native' string along with 'bytes' and
> 'unicode' string in an attempt to try and be able to use one set of
> language which would describe WSGI and be interpretable in the context
> of both Python 2.X and Python 3.X.
> 
> For definition #4, this mean defining SCRIPT_NAME, PATH_INFO and
> QUERY_STRING as 'unicode' string. This meant that for Python 2.X, they
> would as such also be unicode string. The other option was to define
> them as 'native' string, which means the whole 'wsgi.uri_encoding'
> flag was only relevant to Python 3.X, as in Python 2.X the native
> string is 'bytes' and so the whole encoding issue would still be up to
> the WSGI application as it is now for bytes everywhere WSGI in Python
> 2.X. In effect, if they were 'native' strings and 'wsgi.uri_encoding'
> went way, we just have existing WSGI 1.0. The only actual difference
> was that I was adding on top of definition #4 the clarifications as
> per (1) above.

I'd be happy if WSGI 1.1 said "use native" and the "wsgi.uri_encoding"
entry was only required on versions of Python where the native string
type is unicode. That's an extra paragraph in the spec, yes, so violates
my goal 4 a bit, but IMO should not outweigh my goals 1, 2, and 3.

> The second question is, do we want to try and come up with something
> for Python 3.X, ie., (2) above, while still preserving the current
> start_response() callback, or do we instead want to jump direct to
> WSGI (Python 3.X) 2.0, ie., combine (2) and (3) above, and say that
> there is no WSGI 1.X for Python 3.X at all?

I want something in between so I don't have to wait months or years for
WSGI 2. I want to ship a version of CherryPy with Python 3 support last
week.


Robert Brewer
fumanchu at aminus.org