[Web-SIG] PEP 0333 and PEP XXXX Updated

[Armin Ronacher]

Hi,

I know I pretty much SPAM the list here now which is why I added all the
changes of WSGI 1.0 and what could become WSGI 1.1 into a repo on
bitbucket as two PEPS:

http://bitbucket.org/ianb/wsgi-peps/src/


pep-0333.txt

This is basically just a new revision for PEP 333 changing the following
things:

- removing Jython and Python 2.2 compatibility.  Jython is close enough
  to modern Python versions now that this does not make any difference.

- fixing wsgi.input by adding a proper readline().  The current version
  still requires the user to care about not reading past the content
  length, but if all server implementors agree that could be changed so
  that the stream provides an end of line marker.

- mentioning that WSGI 1.0 is not supported by Python 3.

- made WSGI 1.0 depend on bytes.

- fixed example code

- servers may no longer add a date or server header if that header is
  already present.  (This MUST may become a SHOULD for the server
  header as it's probably hard to control for things like mod_wsgi)

- weakened the rules for buffering and streaming.  Everybody does it,
  so it should be allowed.

- added middleware warning for `wsgi.file_wrapper`


pep-XXXX.txt

This specifies WSGI 1.1 based on #3/#4 in Graham Dumpletons Blog post.
The differences to his proposal:

- the application iterator must by byte based.  I would really require
  that, so that people explicitly encode their stuff as utf-8 instead
  of yielding latin1.  If we want to allow unicode return values I
  strongly encourage using utf-8 for the return value because we already
  require UTF-8 URLs.

- clarified wsgi.uri_encoding, that algorithm should not be the default
  but the only one to make it easier for applications to reencode URIs.

- Stick to `start_response` and `exc_info` but add deprecation warnings
  for `exc_info` and `write()`.  This should make it easier to port
  applications over.  Breaking too many APIs at the same time is
  probably not the best idea.


If we really want to get rid of `start_response` at the same time, I
would suggest using ``(appiter, status, headers)`` instead of
``(status, headers, appiter)``.  The former is the current common
signature of response objects which would make it possible to convert
from a WSGI application response to a response object by doing something
like this:

   response = Response(*wsgi_app(request.environ))

The XXXX PEP is currently missing any copyright information and headers
and should only be considered as a draft.


Regards,
Armin