[Web-SIG] Clarifications on Python 3.0 and WSGI.

[Graham Dumpleton]

There has been some prior discussion on Python 3.0 and WSGI. From this
came a number of suggested changes. I list some of these below, but
add a few comments and ask for more feedback.

1. When running under Python 3, applications SHOULD produce bytes
output and headers
2. When running under Python 3, servers and gateways MUST accept
strings as application output or headers, under the existing rules
(i.e., s.encode('latin-1') must convert the string to bytes without an
exception)

In (1), it says that application 'SHOULD produce bytes output and
headers'. In (2), is says 'servers and gateways MUST accept strings as
application output or headers'.

Why are servers and gateways being made to accept strings when the
preference is for applications to produce bytes for both? Is this
acknowledgment that getting people to convert WSGI applications to
produce bytes may be a problem?

The text of (2) sorts of suggests there is justification for this in
saying 'under the existing rules (i.e., s.encode('latin-1') must
convert the string to bytes without an exception', but I can't find
such a rule in the WSGI PEP when I have a quick look. In other words,
where in the existing specification does it say that Unicode strings
must be accepted, to the contrary it suggests they can't be and that
using them where a string object is expected is undefined.

3. When running under Python 3, servers MUST provide CGI HTTP
variables as strings, decoded from the headers using HTTP standard
encodings (i.e. latin-1 + RFC 2047)

Can someone give a practical example of where RFC 2047 fits into this
and how one is meant to handle it?

Thanks.

Graham