On Tue, Sep 21, 2010 at 1:17 PM, P.J. Eby <span dir="ltr">&lt;<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>&gt;</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;">

[trimming reply headers to just web-sig]<br>
<br>
At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby &lt;&lt;mailto:<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>&gt;<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>&gt; wrote:<br>


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>
<br>
<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>
</blockquote>
<br></div>
Are you suggesting a &quot;``str`` for headers, ``bytes`` for bodies&quot; approach instead?<br></blockquote><div><br>Yes. <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;">


I suppose that could work; I was going for &quot;str in, bytes out&quot;.  My assumption, though, was that headers are relatively easy to address at a choke point from a framework&#39;s output.  But I guess that iterator output is equally chokable.<br>

</blockquote><div><br>The request body would still be bytes in either model (at least, I assumed that).<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;">


I&#39;m open to discussion on this point, so long as every value produced or consumed by a WSGI application is of a specified single type().<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Otherwise this seems good to me, the only other major errata I can think of are all listed in the links you included.<br>
</blockquote>
<br></div>
Um, if by &quot;links&quot; you mean, &quot;included textually in the proposal&quot;, then sure.  If it&#39;s not in the proposal, it&#39;s not going in the PEP, even if it&#39;s on the WSGI Amendments page or Graham&#39;s blog.<br>


</blockquote></div><br>Well, at a minimum there is the size hint on wsgi.input.  Things like CONTENT_LENGTH are probably more involved than is necessary for this revision.<br><br clear="all"><br>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>