On Mon, Dec 12, 2011 at 3:40 AM, Chris McDonough <chr...@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?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
