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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
