On Fri, Dec 9, 2011 at 10:11 AM, Barry Warsaw <ba...@python.org> wrote:
> As Chris points out, this seems to be a use case tied to WSGI and PEP > 3333. I > guess it's an unfortunate choice for so recent a PEP, but maybe there was > no > way to do better. For the record, "native strings" are defined the way they are because of IronPython and Jython, which had unicode strings long before CPython. At the time WSGI was developed, the approach for Python 3 (then called "3000") was expected to be similar, and the new I/O system was not (AFAIR) designed yet. All that changed in PEP 3333 was introducing *byte* strings (to accommodate the I/O changes), not native strings. In fact, I'm not sure why people are bringing it into this discussion at all: PEP 3333 was designed to work well with 2to3, which does the right thing for WSGI code: it converts 2.x "str" to 3.x "str", as it should. If you're writing 2.x WSGI code with 'u' literals, *your code is broken*. WSGI doesn't need 'u' literals and never has. It *does* need b'' literals for stuff that refers to request and response bodies, but everything else should be plain old string literals for the appropriate Python version. It can certainly be useful in many contexts outside of WSGI. > And *only* there, pretty much. ;-) PEP 3333 was designed to work with the official upgrade path (2to3), which is why it has a concept of native strings. Thing is, if you mark them with a 'u', you're writing incorrect code for 2.x.
_______________________________________________ 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
