On Wed, Jul 14, 2010 at 12:04 AM, Graham Dumpleton <span dir="ltr">&lt;<a href="mailto:graham.dumpleton@gmail.com">graham.dumpleton@gmail.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 14 July 2010 14:43, Ian Bicking &lt;<a href="mailto:ianb@colorstudy.com">ianb@colorstudy.com</a>&gt; wrote:<br>
&gt; So... there&#39;s been some discussion of WSGI on Python 3 lately.  I&#39;m not<br>
&gt; feeling as pessimistic as some people, I feel like we were close but just<br>
&gt; didn&#39;t *quite* get there.<br>
<br>
</div>What I took from the discussion wasn&#39;t that one couldn&#39;t specify a<br>
WSGI interface, and as you say we more or less have one now, the issue<br>
is more about how practical that is from a usability perspective for<br>
those who have to code stuff on top.<br></blockquote><div><br>My intuition is that won&#39;t be that bad.  At least compared to any library that is dealing with str/unicode porting issues; which aren&#39;t easy, but so it goes.<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;"><div class="im"><br>
&gt; * I&#39;m terrible at naming, but let&#39;s say these new values are RAW_SCRIPT_NAME<br>
&gt; and RAW_PATH_INFO.<br>
<br>
</div>My prior suggestion on that since upper case keys for now effectively<br>
derive from CGI, was to make them wsgi.script_name and wsgi.path_info.<br>
Ie., push them into the wsgi namespace.<br></blockquote><div><br>That&#39;s fine with me too.<br> </div><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">
&gt; Does this solve everything?  There&#39;s broken stuff in the stdlib, but we<br>
&gt; shouldn&#39;t bother ourselves with that -- if we need working code we should<br>
&gt; just write it and ignore the stdlib or submit our stuff as patches to the<br>
&gt; stdlib.<br>
<br>
</div>The quick summary of what I suggest before is at:<br>
<br>
  <a href="http://code.google.com/p/modwsgi/wiki/SupportForPython3X" target="_blank">http://code.google.com/p/modwsgi/wiki/SupportForPython3X</a><br>
<br>
I believe the only difference I see is the raw SCRIPT_NAME and<br>
PATH_INFO, which got discussed to death previously with no consensus.<br></blockquote><div><br>Thanks, I was looking for that.  I remember the primary objection to a SCRIPT_NAME/PATH_INFO change was from you.  Do you still feel that way?<br>

<br>I generally agree with your interpretation, except I would want to strictly disallow unicode (Python 3 str) from response bodies.  Latin1/ISO-8859-1 is an okay encoding for headers and status and raw SCRIPT_NAME/PATH_INFO, but for bodies it doesn&#39;t have any particular validity.<br>

<br>I forgot to mention the response, which you cover; I guess I&#39;m okay with being lenient on types there (allowing both bytes and str in Python 3)... though I&#39;m not really that happy with it.  I&#39;d rather just keep it symmetric with the request, requiring native strings everywhere.<br>

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