On Fri, Dec 9, 2011 at 04:34, Barry Warsaw <ba...@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. _______________________________________________ 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