On Fri, Jul 16, 2010 at 5:08 PM, Chris McDonough <span dir="ltr">&lt;<a href="mailto:chrism@plope.com">chrism@plope.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Fri, 2010-07-16 at 17:47 -0400, Tres Seaver wrote:<br>
<br>
&gt; &gt; In the past when we&#39;ve gotten down to specifics, the only holdup has been<br>
&gt; &gt; SCRIPT_NAME/PATH_INFO, hence my suggestion to eliminate those.<br>
&gt;<br>
&gt; I think I favor PJE&#39;s suggestion:  let WSGI deal only in bytes.<br>
<br>
</div>I&#39;d prefer that WSGI 2 was defined in terms of a &quot;bytes with benefits&quot;<br>
type (Python 2&#39;s ``str`` with an optional encoding attribute as a hint<br>
for cast to unicode str) instead of Python 3-style bytes.<br>
<br>
But if I had to make the Hobson&#39;s choice between Python 3 style bytes<br>
and Python 3 style str, I&#39;d choose bytes.  If I then needed to write<br>
middleware or applications, I&#39;d use WebOb or an equivalent library to<br>
enable a policy which converted those bytes to strings on my behalf.<br>
Making it easy to write &quot;raw&quot; middleware or applications without using<br>
such a library doesn&#39;t seem as compelling a goal as being able to easily<br>
write one which allowed me direct control at the raw level.<br></blockquote><div><br>What are the concrete problems you envision with text request headers, text (URL-quoted) path, and text response status and headers?<br>

 </div></div>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>