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

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.