[Python-Dev] readd u'' literal support in 3.3?

PJ Eby pje at telecommunity.com
Fri Dec 9 20:58:10 CET 2011

On Fri, Dec 9, 2011 at 10:11 AM, Barry Warsaw <barry at 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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20111209/bf0c5e73/attachment.html>

More information about the Python-Dev mailing list