<div class="gmail_quote">On Mon, Dec 12, 2011 at 3:40 AM, Chris McDonough <span dir="ltr"><<a href="mailto:chrism@plope.com">chrism@plope.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Truth be told, in the vast majority of WSGI apps only high-level WSGI<br>
libraries (like WebOb and Werkzeug) and standalone middleware really<br>
needs to work with native strings. And the middleware really should be<br>
using the high-level libraries to parse WSGI anyway. So there are a<br>
finite number of places where it's actually a real issue.<br></blockquote><div><br></div><div>And those only if they're using "six" or a similar joint-codebase strategy, *and* using unicode_literals in a 2.x module that also does WSGI. If they're using 2to3 and stick with explicit u'', they'll be fine.</div>
<div><br></div><div>Unfortunately, AFAIR, nobody in the PEP 3333 discussions brought up either the unicode_literals import OR the strategy of using a common codebase, so 2to3 on plain code and writing new Python3 code were the only porting scenarios discussed. (Not that I'm sure it would've made a difference, as I'm not sure what we could have done differently that would still support simple Python3 code and easy 2to3 porting.)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As someone who ported WebOb and other stuff built on top of it to Python<br>
3 without using "from __future__ import unicode_literals", I'm kinda sad<br>
that to be using best practice I'll have to go back and flip the<br>
polarity on everything.</blockquote><div><br></div><div>Eh? If you don't need unicode_literals, what's the problem?</div></div>