4 ms·
> How hard would it have been to support u so someone could support both versions more easily? Exceptionally hard. Py2 str objects are tantamount to py3 bytes
by kortex 5y ago
> How hard would it have been to support u so someone could support both versions more easily?
Exceptionally hard. Py2 str objects are tantamount to py3 bytes but with the py3 str apis. What this amounts to is every "str" in py2 is an untagged union of str/bytes. Python is exceptionally dynamic. This means if you allow different behavior in different modules, you risk silent, customer-data-corrupting bugs, among other headaches, as things continue to "work" but do the wrong thing.
At least with a hard 2/3 switch, you are on your toes and know there is a (mostly) finite transition period.
from __future__ import str basically guarantees you'll have "3-compatible code" causing headaches years into the future.
That's not even to touch on the difficulty of switching the engineering difficulty of interop of encoding-oblivious strings with unicode ones.
- pseudalopex 5y agoPython 2 let you put a u in front of a string literal to make it unicode. Python 3 made it a syntax error at first. Python 3.3 restored it so people could write code compatible with 2 and 3 without importing unicode_literals.