4 ms·
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 wi
by jordanb 11mo 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 11mo 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 11mo agoI 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 11mo agoWhat 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 11mo agoWith 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 11mo 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 11mo agoIt 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 11mo agoI 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 11mo agoPain 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 11mo ago[deleted]
- 11mo ago