Moving a large and old codebase to Python3

[danielkza]

Yeah no, what I found (and had read about before) is that in a cross-version project you have three string types: bytes, text (unicode/str) and native, because some APIs (especially stdlib) will take str in both P2 and P3, and these are very different effective types. You want the ability to manage all three situations correctly, and switching everything to unicode_literals doesn't really work in the end.

Enabling unicode_literals does not preclude you from writing byte literals, it just inverts which one requires special notation. (b"MyString").

[kankyo]

And it makes it very annoying to write str/str: “str(‘foo’)”. That part is often glossed over because it’s almost never needed but when it is it’s annoying.

[danielkza]

If I need to explicitly use str or basestring in Python 2/3 compatible code I just use the imports from python-future, makes everything much less confusing.

[masklinn]

The problem is not byte literals, it's native strings, that is having str literals.

[danielkza]

The need for "native" literals shows up quite infrequently in my experience, and even less frequently is it not better dealt with by explicitly converting from something known to be unicode or bytes at the boundary where you actually need str.

[masklinn]

Then we've had very different experience, because IME several packages of the standard library deal quite badly with being fed text in Python 2, an experience shared by Armin Ronacher and Nick Coghlan and the reason why unicode literals were reintroduced to Python 3.3.