On Fri, Jul 16, 2010 at 5:08 PM, Chris McDonough <span dir="ltr"><<a href="mailto:chrism@plope.com">chrism@plope.com</a>></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>
> > In the past when we've gotten down to specifics, the only holdup has been<br>
> > SCRIPT_NAME/PATH_INFO, hence my suggestion to eliminate those.<br>
><br>
> I think I favor PJE's suggestion: let WSGI deal only in bytes.<br>
<br>
</div>I'd prefer that WSGI 2 was defined in terms of a "bytes with benefits"<br>
type (Python 2'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's choice between Python 3 style bytes<br>
and Python 3 style str, I'd choose bytes. If I then needed to write<br>
middleware or applications, I'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 "raw" middleware or applications without using<br>
such a library doesn'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>