Have you read the threads on WSGI 2?  These issues are discussed at length, though they haven&#39;t been put into a spec.<div><br></div><div>The proposal that seemed to work best was to keep the environ as str (i.e., unicode in Python 3), and eliminate the problematic SCRIPT_NAME and PATH_INFO, replacing them with url-encoded values.  Also I think everyone is okay with removing start_response.  All text would be decoded as latin1 on Python 3 (which allows for transcoding; also most text is not unicode).  The request and response body would remain bytes.<br>

<br><div class="gmail_quote">On Tue, Nov 24, 2009 at 2:58 AM, Malthe Borch <span dir="ltr">&lt;<a href="mailto:mborch@gmail.com">mborch@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I disagree that the current 1.x track of the WSGI specification [1] supports Python 3 in any reasonable way. Recently I suggested the following rule as a guideline [2]:<br>
<br>
  Strings should be strings, chunks should be bytes.<br>
<br>
What this really suggests is that everything that looks and feels like a human-readable string (almost everything in HTTP except the input content and the output response) should be a (unicode) string. As I read the proposed 1.1 revision, this is not the case.<br>


<br>
However, there is another fish to fry here too, and I&#39;d like to propose a new 2.x track altogether. In the outset, this would pertain to Python 3 only.<br>
<br>
Instead of passing ``environ`` and violate its contract by adding &#39;wsgi.*&#39; entries, we must pass in an object which actually represents the HTTP request, e.g.<br>
<br>
  Request = namedtuple(&quot;Request&quot;, &quot;environ input&quot;)<br>
<br>
There could be other properties of this request-object. I haven&#39;t considered the details.<br>
<br>
To consider for this track is also the possibility of changing the application call signature (I heard this proposal from Daniel Holth, but it&#39;s probably been suggested before):<br>
<br>
  def __call__(self, request):<br>
      return status, headers, app_iter<br>
<br>
I don&#39;t mind ``start_response`` terribly, but it&#39;s worth discussing. Certainly returning this triple makes things easier.<br>
<br>
\malthe<br>
<br>
[1] <a href="http://bitbucket.org/ianb/wsgi-peps/src/tip/pep-0333.txt" target="_blank">http://bitbucket.org/ianb/wsgi-peps/src/tip/pep-0333.txt</a><br>
[2] <a href="http://mockit.blogspot.com/2009/11/dont-look-back-in-anger.html" target="_blank">http://mockit.blogspot.com/2009/11/dont-look-back-in-anger.html</a><br>
<br>
_______________________________________________<br>
Web-SIG mailing list<br>
<a href="mailto:Web-SIG@python.org" target="_blank">Web-SIG@python.org</a><br>
Web SIG: <a href="http://www.python.org/sigs/web-sig" target="_blank">http://www.python.org/sigs/web-sig</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/web-sig/ianb%40colorstudy.com" target="_blank">http://mail.python.org/mailman/options/web-sig/ianb%40colorstudy.com</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a>  |  <a href="http://topplabs.org/civichacker">http://topplabs.org/civichacker</a><br>
</div>