On Fri, Jul 16, 2010 at 12:28 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 11:07 -0500, Ian Bicking wrote:<br>
<br>
&gt; And this doesn&#39;t help with Python 3: either we have byte values of<br>
&gt; SCRIPT_NAME and PATH_INFO in Python 3, or we have text values.  I<br>
&gt; think bytes will be more awkward to port to than text, and<br>
&gt; inconsistent with other WSGI values.  If we have text then we have to<br>
&gt; choose an encoding.  Latin1 will work, but it will be the exact wrong<br>
&gt; encoding most of the time as UTF-8 is the typical  (unlike other<br>
&gt; headers, where Latin1 will mostly be an okay encoding, or as good a<br>
&gt; guess as we have).  If we firmly remove these keys then we can avoid<br>
&gt; this choice entirely... and we conveniently also get a better<br>
&gt; representation of the request.<br>
<br>
</div>My $.02: I&#39;d rather lobby the core folks for a string ABC (which we can<br>
hook with a stringlike bytes type) and consider all 3.X releases made so<br>
far &quot;dead to WSGI&quot; than to have to tunnel arbitrary bytes through some<br>
misleading Unicode encoding.<br></blockquote></div><br>While I think it would be generally useful, it&#39;s also a long way off at best, with serious performance dangers that could torpedo the whole thing.  But... I&#39;m also unsure how it would help here, except perhaps we could incrementally annotate bytes with an encoding?  Well, I don&#39;t really know.  Treating the raw request path as text is easy enough, as it should always be ASCII anyway.  We don&#39;t have to worry what is &quot;right&quot; or &quot;wrong&quot; in this case.<br>

<br>We could make everything bytes and be done with it, but it would make it much harder to port Python 2 WSGI code to Python 3.<br clear="all"><br>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>