I think you've just proved OP's point...you have to change the code.

Alternatively, we need to quite ignoring when projects warn about changing behavior and provide tools to mitigate the change.

  __future__.division was optional in 2.0.0, which was released in 2001

  __future__.print_function was optional in 2.6.0a2, which was released in 2008

There is nothing a language team can do if users ignore changes for close to two decades.

Simply adding the following line to new project over the past 8 years would have made the move to python 3 less difficult.

  from __future__ import (division, print_function)

While I am annoyed that they didn't just alias xrange to range etc...us users do need to take ownership for our bad decisions.

You have to change the code a lot more to port it to an entirely different language.

Of course, but the point is that you shouldn't really need to spend weeks updating your code just to upgrade to a newer version of the compiler.

I know right, you usually have to change a lot of code just to change versions of a framework.

One of my teammates just upgraded our django framework from 1.4 to 1.8 and it took him almost an entire week to do.

A week! It took me six months to port our main app from django 1.5 to 1.8. Though our app is huge, and most of that was migrating from DRF 2.3 to 3.3.

You can use to 2to3 command. So far I had no problems while using it.

https://docs.python.org/3/library/2to3.html