This is in part due to a lack of foresight, but you can run into all sorts of weird issues that you'd never think of, like this one: we have a feature in our REST API that can return lists of items as CSV instead of JSON (yes, I know, it sounds weird). It requires no effort from our backend services; the api proxy takes care of it. Unfortunately, something changed with dict enumeration order between python 2 and 3, and so when we first tried to upgrade, the CSV files being spit out had a new column ordering, which of course would have broken customer code that relied on it.
The string-handling changes, while necessary, are also a bear to deal with. Since python is dynamically typed, you need to work to find all the places where you need to add a ".decode()" or ".encode()". If you don't have excellent test coverage already, you're going to miss some, and it'll be a game of whack-a-mole until you get them all... assuming you have actually gotten them all.
> something changed with dict enumeration order between python 2 and 3
Dicts were by definition unordered until Python 3.7 [0], so you were relying on undefined behaviour. If you need an ordered dictionary and support Python 3.6 or below, you should use OrderedDict [1].
> something changed with dict enumeration order between python 2 and 3
Enumeration order in dict keys was never guaranteed (until 2019), even on 2. So basically that code relied on undocumented cpython behaviour that was strongly advised against, i.e. it was broken already. 3 simply made the brokenness more visible.
The string-handling changes, while necessary, are also a bear to deal with. Since python is dynamically typed, you need to work to find all the places where you need to add a ".decode()" or ".encode()". If you don't have excellent test coverage already, you're going to miss some, and it'll be a game of whack-a-mole until you get them all... assuming you have actually gotten them all.