The wsgiref "simple server" module has a demo server, which fails to
start in Python 3.0 for a bunch of reasons.

To verify this, just go into the Lib/wsgiref directory, and run:
python3.0 ./simple_server.py
(which launches the demo server).

This opens your web browser and points it at the server, and you get the
following error:

ValueError: need more than 1 value to unpack

I fixed a number of issues which simply killed the server:

• In get_environ, it did not iterate over the headers mapping properly
  at all (was expecting a sequence of strings, it actually is a mapping).
  I think the email.message.Message class changed. Fixed.
• In demo_app, it calls sort on the output of dict.items() - a list in
  Python 2, but an iterator in Python 3, so it fails. Fixed (using "sorted").

Unfortunately, the final issue is a bit harder to fix. It seems when I
run the demo server, it opens a binary stream, but handlers.py sends
strings to be written, giving the error

TypeError: send() argument 1 must be bytes or read-only buffer, not str

However in the test case, it opens a text stream, so handlers.py works fine.

The following *HACK* fixes it so the demo server works, but breaks the
test suite (it is NOT included in the attached patch):

--- Lib/wsgiref/handlers.py	(revision 64895)
+++ Lib/wsgiref/handlers.py	(working copy)
@@ -382,8 +382,8 @@
         self.environ.update(self.base_env)
 
     def _write(self,data):
-        self.stdout.write(data)
-        self._write = self.stdout.write
+        self.stdout.write(data.encode('utf-8'))
+        #self._write = self.stdout.write
 
I can't figure out right away what to do about this, but the best
solution would be to get the demo server to open the socket in text mode.

In any case, the patch is attached for branch /branches/py3k, revision
64895.

Commit log:

• Lib/wsgiref/simple_server.py: Fixed two fatal errors which prevent the
  demo server from running (broken due to Python 3.0).
  Note: Demo server may still not run due to an issue between strings and
  bytes.

The encoding must be latin-1, not utf-8, and the stream must be binary
mode, not text.

I have no idea how to deal with the test suite, and don't have time at
the moment to investigate.

Are you saying the stream passed to _write SHOULD always be a binary
stream, and hence the test case is wrong, because it opens a text stream?

(I'm not sure where the stream comes from, but we should guarantee it's
a binary stream).

Also, why Latin-1?

For the "why Latin-1", read the WSGI spec's explanation of how
strings should be handled in Python implementations where 'str' is unicode.

I suppose that you *could* make it a text stream with Latin-1
encoding; I'm just not clear on whether there are any other ramifications.

Wow, I read the WSGI spec. That seems very strange that it says "HTTP
does not directly support Unicode, and neither does this interface."
Clearly HTTP *does* support Unicode, because it allows you to specify an
encoding.

I assume then that the ISO-8859-1 characters the WSGI functions receive
will be treated as byte values. (That's rather silly; it's just dodging
the issue of Unicode rather than supporting it).

But in any event, the PEP has spoken, so we stick with Latin-1.

With respect to the text/binary stream, I think it would be best if it's
a binary stream, and we explicitly convert those str objects (which WSGI
says must only contain Latin-1 range characters) into bytes objects
(simply treating code points as bytes; in other words calling
.encode('latin-1')) and writing them to the binary stream. (Since the
WSGI spec is so adamant we deal in bytes).

HTTP is defined as a stream of bytes; the fact that you can specify
encodings for headers and content is a different level of the
spec. WSGI wants to basically be as transparent a mapping as
possible between HTTP and Python data structures, without imposing
any *new* higher-level structures or conventions.

Also reported in bpo-3795.
PJE, are you willing to work on this some day?

Not any time soon; I don't currently use Py3K and can't even vouch for
the correctness of the posted patch within Py3K. (i.e., what really
happened to the message class?) Sorry; all I can really do here is
clarify WSGI-related questions.

There's a proper patch in bpo-4718, marking this one in duplicate.