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

Lennart Regebro regebro at gmail.com
Fri Dec 9 15:18:33 CET 2011

On Fri, Dec 9, 2011 at 04:34, Barry Warsaw <barry at python.org> wrote:
> Sorry, I don't understand this.  What does it mean to be "str in both
> versions"?  And why would you want that?

It means that it's a str, that is a string of bytes, in Python 2, and
a str, that is a string of Unicode characters, in Python 3. There are
cases where you want this, for example not all libraries will accept
both str and Unicode under Python 2.

> As for "Unicode in Python 2 and str in Python 3", unadorned strings with the
> future import in Python >= 2.6 does that just fine.

Yes, but the future import will change this for *all* strings, making
it impossible to have a string that is a "str" in both Python 2 and
Python 3. For that reason, the future import is not enough as a
solution (and I suspect, one major reason why I haven't actually seen
any one using it).

For most cases, using something like six's b() and u() has turned out
to be a better solution. It's uglier than having u'' support in Python
3, but has the benefit that b() works also in Python 2.5.

> The
> problem comes when you aren't or can't be sure, i.e. you have objects that are
> sometimes one and sometimes the other.  Such as email headers.  In that case,
> you're kind of screwed.  Python 2's str type let you cheat, but not without
> consequences.  Those consequences are spelled "UnicodeErrors" and I'll be glad
> to be rid of them.

Me too.

More information about the Python-Dev mailing list