[cpncrunch]

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

[nyrikki]

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.

[rspeer]

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

[cpncrunch]

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.

[mrep]

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.

[craigds]

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.

[hsjoberg]

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

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