6 ms·

Python 3 was a disaster and enterprises were still undertaking pointless 2->3 upgrade projects 10 years later

zihotki 9mo ago
A month ago I had to fix a small bug in Python 2.6 code in one of internal systems. It won't be ever migrated, no capacity and no value
jordanb 9mo ago
It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode. Organizations struggled with it but they struggle with basically every breaking change. I was on the tooling team that helped an organization handle the transition of about 5 million lines of data science code from python 2.7 to 3.2. We also had to handle other breaking changes like airflow upgrades, spark 2->3, intel->amd->graviton. At that scale all those changes are a big deal. Heck even the pickle protocol change in Python 3.8 was a big deal for us. I wouldn't characterize the python 2->3 transition as a significantly bigger deal than some of the others. In many ways it was easier because so much hay was made about it there was a lot of knowledge and tooling.
- xscott 9mo ago
  > It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode. They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood. Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.
  - MangoToupe 9mo ago
    I can't say i've ever thought "wow I wish I had to use go's unicode approach". The bytes/str split is the cleanest approach of any runtime I've seen.
  - zahlman 9mo ago
    What you propose would have, among other things, broken the well established expectation of random access for strings, including for slicing, while leaving behind unclear semantics about what encoding was used. (If you read in data in a different encoding and aren't forced to do something about it before passing it to a system that expects UTF-8, that's a recipe for disaster.) It would also leave unclear semantics for cases where the underlying bytes aren't valid UTF-8 data (do you just fail on every operation? Fail on the ones that happen to encounter the invalid bytes?), which in turn is also problematic for command-line arguments.
- JoshTriplett 9mo ago
  With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.
  - MangoToupe 9mo ago
    > With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Not without enormous and unnecessary pain.
    - JoshTriplett 9mo ago
      It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
      - MangoToupe 9mo ago
        I think you have causation reversed: it would have been at least two orders of magnitude greater to act like moving to python 3 was harder than staying. But you do you boo :emoji-kissey-face:
    - SoftTalker 9mo ago
      Pain on whose part? There was certainly pain porting all the code that had to be ported to Python 3 so that the Python developers could have an easier time.
      - deleted 9mo ago
        [deleted]
      - 9mo ago
MangoToupe 9mo ago
It was not a disaster in any way. People just complained about having to do something to upgrade their codebases.
bsder 9mo ago
Except that Python took the other path when migrating from Python 1 to Python 2 and ... guess what? That was a "disaster" too. The only difference was that by the time of Python 3, Python programs were orders of magnitude bigger so the pain was that much worse.
- symbogra 9mo ago
  Differences of scale do make a qualitative difference and must be considered when doing a migration.

A month ago I had to fix a small bug in Python 2.6 code in one of internal systems. It won't be ever migrated, no capacity and no value

jordanb 9mo ago

It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode. Organizations struggled with it but they struggle with basically every breaking change. I was on the tooling team that helped an organization handle the transition of about 5 million lines of data science code from python 2.7 to 3.2. We also had to handle other breaking changes like airflow upgrades, spark 2->3, intel->amd->graviton. At that scale all those changes are a big deal. Heck even the pickle protocol change in Python 3.8 was a big deal for us. I wouldn't characterize the python 2->3 transition as a significantly bigger deal than some of the others. In many ways it was easier because so much hay was made about it there was a lot of knowledge and tooling.

xscott 9mo ago
> It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode. They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood. Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.
- MangoToupe 9mo ago
  I can't say i've ever thought "wow I wish I had to use go's unicode approach". The bytes/str split is the cleanest approach of any runtime I've seen.
- zahlman 9mo ago
  What you propose would have, among other things, broken the well established expectation of random access for strings, including for slicing, while leaving behind unclear semantics about what encoding was used. (If you read in data in a different encoding and aren't forced to do something about it before passing it to a system that expects UTF-8, that's a recipe for disaster.) It would also leave unclear semantics for cases where the underlying bytes aren't valid UTF-8 data (do you just fail on every operation? Fail on the ones that happen to encounter the invalid bytes?), which in turn is also problematic for command-line arguments.
JoshTriplett 9mo ago
With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.
- MangoToupe 9mo ago
  > With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Not without enormous and unnecessary pain.
  - JoshTriplett 9mo ago
    It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
    - MangoToupe 9mo ago
      I think you have causation reversed: it would have been at least two orders of magnitude greater to act like moving to python 3 was harder than staying. But you do you boo :emoji-kissey-face:
  - SoftTalker 9mo ago
    Pain on whose part? There was certainly pain porting all the code that had to be ported to Python 3 so that the Python developers could have an easier time.
    - deleted 9mo ago
      [deleted]
    - 9mo ago

MangoToupe 9mo ago

It was not a disaster in any way. People just complained about having to do something to upgrade their codebases.

bsder 9mo ago

Except that Python took the other path when migrating from Python 1 to Python 2 and ... guess what? That was a "disaster" too. The only difference was that by the time of Python 3, Python programs were orders of magnitude bigger so the pain was that much worse.

symbogra 9mo ago
Differences of scale do make a qualitative difference and must be considered when doing a migration.