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

Antoine Pitrou solipsis at pitrou.net
Fri Dec 9 09:54:15 CET 2011

On Fri, 9 Dec 2011 15:30:36 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> Or, alternatively, you use 'six' (or a similar compatibility module)
> and ensure unicode at runtime, using native or binary strings
> otherwise:
> ----------
> from six import u
> foo = u("this is a Unicode string in both Python 2.x and 3.x")
> bar = "this is an 8-bit string in Python 2.x and a Unicode string in 3.x"
> baz = b"this is an 8-bit string in Python 2.x and a bytes object in 3.x"
> ----------
> If you want to target 3.2, you *have* to use one of those mechanisms -
> any potential restoration of u'' syntax support won't help you (and
> even after 3.3 gets released in the latter half of next year, it's
> still going to be a fair while before it makes it's way into the
> various distros, especially the ones that include long term support
> from major vendors).
> So, instead of attempting to paper over the problem by reintroducing
> u'', perhaps the discussion we should be having is whether or not PEP
> 3333's superficially appealing concept of defining an API in terms of
> "native strings" is a loser in practice, and we should instead be
> looking more closely at PEP 444

It's not only PEP 3333. Many network protocol implementations will
show the same characteristics (an FTP implementation accepting str in
2.x will also want to accept str in 3.x). But using six is a reasonable
suggestion for those who want to share a single codebase accross 2.x
and 3.x.



More information about the Python-Dev mailing list