(original) (raw)

On Mon, Dec 12, 2011 at 3:40 AM, Chris McDonough <chrism@plope.com> wrote:

Truth be told, in the vast majority of WSGI apps only high-level WSGI
libraries (like WebOb and Werkzeug) and standalone middleware really
needs to work with native strings. �And the middleware really should be
using the high-level libraries to parse WSGI anyway. �So there are a
finite number of places where it's actually a real issue.

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.

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.)

As someone who ported WebOb and other stuff built on top of it to Python
3 without using "from \_\_future\_\_ import unicode\_literals", I'm kinda sad
that to be using best practice I'll have to go back and flip the
polarity on everything.

Eh? �If you don't need unicode\_literals, what's the problem?