This is my attempt to be sympathetic to the GP's point of view, perhaps they have a different example in mind. One example comes from the new-style / old-style

This is my attempt to be sympathetic to the GP's point of view, perhaps they have a different example in mind. One example comes from the new-style / old-style classes distinction and the method resolution order when considering multiple inheritance. Python 2.3 introduced "new-style" classes which inherit from `object` and use the C3 resolution algorithm [1]. For backwards compatibility reasons, "old-style" classes without an explicit `object` base class still used the old method resolution semantics. Python 3 does away with "old-style" classes entirely and all classes must use the "new-style" semantics. There's presumably a ton of code that doesn't specify `object` as an explicit base class, and thus may have subtle broken behaviour under "new-style". Given Python 3's inability / unwillingness to simulate the old behaviour, I'm unaware of any tool that's able to rewrite Python 2 to 3 in a bullet proof fashion [2]. This is not the same kind of breakage that other people mention, like `print` being a function or `reduce` being moved to `functools`. Those are simply backwards incompatible "movements", not outright removals, and thus can be rewritten by automated tools. [1] https://www.python.org/download/releases/2.3/mro/ https://www.python.org/download/releases/2.3/mro/ [2] https://portingguide.readthedocs.io/en/latest/classes.html#new-style-classes https://portingguide.readthedocs.io/en/latest/classes.html#n...