On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The Python 3 specific changes are to use:<br>
<br>
* ``bytes`` for I/O streams in both directions<br>
* ``str`` for environ keys and values<br>
* ``bytes`` for arguments to start_response() and write()<br>
</blockquote><div><br>This is the only thing that seems odd to me -- it seems like the response should be symmetric with the request, and the request in this case uses str for headers (status being header-like), and bytes for the body.<br>
<br>Otherwise this seems good to me, the only other major errata I can think of are all listed in the links you included.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* text stream for wsgi.errors<br>
<br>
In other words, "strings in, bytes out" for headers, bytes for bodies.<br>
<br>
In general, only changes that don't break Python 2 WSGI implementations are allowed. The changes should also not break mod_wsgi on Python 3, but may make some Python 3 wsgi applications non-compliant, despite continuing to function on mod_wsgi.<br>
<br>
This is because mod_wsgi allows applications to output string headers and bodies, but I am ruling that option out because it forces every piece of middleware to have to be tested with arbitrary combinations of strings and bytes in order to test compliance. If you want your application to output strings rather than bytes, you can always use a decorator to do that. (And a sample one could be provided in wsgiref.)<br>
</blockquote><div><br>I agree allowing both is not ideal.<br clear="all"><br></div></div><br>-- <br>Ian Bicking | <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>