[Web-SIG] PEP 444 (aka Web3)

[Armin Ronacher]

Hi,

Here some things comments summarized and how things will change:

- The order of the response tuple.
   The majority of this list wants it to be changed to the standard
   (status, headers, body) format, and we agree.  The original
   motivation was passing it to the constructor of a common
   response object, but there is no reason this shouldn't be changed.
   Will update the PEP and implementation appropriately.

- The async part.  It was added in the hope that someone would step up
   and come up with something better as replacement.  I asked in the
   #twisted IRC channel but they did not see any value in supporting
   a common specification that was shared with the synchronous world
   and it looks like it will be harder to find someone that does care
   about this particular issue.

   The motivation was that facebook's tornado framework is currently
   attracting a lot of users and creating an environment besides the
   WSGI one which means that it might be quite hard to share some code
   between those two worlds.

   I also remember hearing a lot of backlash when start_response was
   considered for deleting last time from the nginx mod_wsgi
   maintainer.

   If I can't find someone that is willing to provide some input on that
   I will remove that section.

- Bytes values in the environment:

   HTTP transmits bytes, that's a fact we can't change.  When we go
   with native strings we will go with unicode on 3.x  This has the
   following implications:

   - getting the right path info requires a decode + an encode
     unless you are assuming latin1.
   - same as above for the script name and cookie header

   When going with unicode strings on 3.x for environ values, we would
   have to do the same for outgoing values which makes middlewares a lot
   harder to write:

   - header keys and values might then be bytes and unicode strings.
     Because of this all middlewares would have to convert to either
     str objects or bytes which might mean a lot of extra encoding and
     decoding depending on how the middleware is implemented.
   - We can't change the fact that a large percentage of Python
     developers is living in an ASCII-only world which would never
     have to deal with encodings that way and might be encouraged to
     just assume ASCII as encoding.

   For implementations not based on the standard library the bytes-only
   approach seems to be easier in any way as far as I can see.  The
   only real issue appears to be urllib for the moment, and until that
   is resolved one could easily do an encode/decode around the calls
   to that particular library.

- web3.errors

   I think Ian raised concern that it's specified to support unicode
   only.  I don't think we should change that to accepting either bytes
   or unicode is a good idea on Python 3 where there is no stream in
   the language or standard library that accepts both at the same time.
   An implementation for 2.x could support both, but I don't know if
   there is a usecase for that.  In general though I have to say that
   very few people use wsgi.errors currently, so I don't think this is
   a real issue anyways.

- the web3 name

   If there is any value in this PEP and we find something to decide on,
   there is no reason this couldn't be WSGI 2.  But until it's just
   something a small part of the web-sig community worked on directly
   a separate name is a good thing I think, because it does not reserve
   the name "WSGI 2" for something that might actually become WSGI 2
   in case this PEP gets rejected.


Regards,
Armin