3 ms·

Eh, the Unicode situation was irredeemably awful in Python 2 because of the era it was of. Fixing that could never have fitted into what you describe. It had to

Eh, the Unicode situation was irredeemably awful in Python 2 because of the era it was of. Fixing that could never have fitted into what you describe. It had to be a significant breaking change, and even if Python 3’s string handling isn’t perfect (its strings are sequences of Unicode code points, not Unicode scalar values, so they can be ill-formed which was madness to allow; I say they should have gone all in on UTF-8 instead, which trades away some sorely misleading, tempting but practically quite useless functionality in favour of performance and memory usage), it’s vastly better than the situation in Python 2, where you pretty much just couldn’t be sure of anything—on many common configurations, you couldn’t even reliably output Unicode, and might not be able to at all without setting the PYTHONIOENCODING=utf-8 environment variable before starting Python, if my memory serves me correctly (I am glad to say that I haven’t had to deal with python2 for five years now).

tyingq 5y ago
True, though that's one of the things that 2to3 couldn't deal with, because it's not possible to do so automatically. It can't have had any idea what was supposed to remain a string, and what was supposed to become bytes.
- tobiasSoftware 5y ago
  My problem was that there were other unspecified things that 2to3 couldn't deal with. Imagine the world where the upgrade guide was to run 2to3 and then it had explanations of how to address the remaining string issues. Instead, I found the attitude of "run 2to3, it'll probably work but if it doesn't, then you'll have to figure it out yourself."
tobiasSoftware 5y ago
In my opinion, the issue was that they used this feature as an excuse to have other breaking features that weren't really needed. I think besides the string upgrade, every other breaking feature should have worked with 2 to 3. Then they could have had a clear upgrade guide that is to run 2 to 3, then clear explanations on how to fix all the remaining string issues. Instead, I have no clue what 2 to 3 fixes and what it doesn't, leading to "2 to 3 will probably work, but if it doesn't, then you'll just have to figure it out yourself." That's unacceptable, and as a result caused many libraries to take a long time to upgrade. Personally, I had to spend 10 YEARS to wait to upgrade to Python 3 due to the wxPython library that all of my projects used that took that long to upgrade to Python 3.
dekhn 5y ago
yeah, I forgot to include unicode but I actually think they should have completed the print() and integer division change migration (without a major version bump, with import futures) and then done a major version bump (to 3) specifically for Unicode. And I agree- utf-8 has clearly established itself as the preferred encoding.

tyingq 5y ago

True, though that's one of the things that 2to3 couldn't deal with, because it's not possible to do so automatically. It can't have had any idea what was supposed to remain a string, and what was supposed to become bytes.

tobiasSoftware 5y ago
My problem was that there were other unspecified things that 2to3 couldn't deal with. Imagine the world where the upgrade guide was to run 2to3 and then it had explanations of how to address the remaining string issues. Instead, I found the attitude of "run 2to3, it'll probably work but if it doesn't, then you'll have to figure it out yourself."

tobiasSoftware 5y ago

In my opinion, the issue was that they used this feature as an excuse to have other breaking features that weren't really needed. I think besides the string upgrade, every other breaking feature should have worked with 2 to 3. Then they could have had a clear upgrade guide that is to run 2 to 3, then clear explanations on how to fix all the remaining string issues. Instead, I have no clue what 2 to 3 fixes and what it doesn't, leading to "2 to 3 will probably work, but if it doesn't, then you'll just have to figure it out yourself." That's unacceptable, and as a result caused many libraries to take a long time to upgrade. Personally, I had to spend 10 YEARS to wait to upgrade to Python 3 due to the wxPython library that all of my projects used that took that long to upgrade to Python 3.

dekhn 5y ago

yeah, I forgot to include unicode but I actually think they should have completed the print() and integer division change migration (without a major version bump, with import futures) and then done a major version bump (to 3) specifically for Unicode. And I agree- utf-8 has clearly established itself as the preferred encoding.