The migration could have happened more smoothly if they had let both python2 and python3 code coexist in the same project. The problem was forking the language

The migration could have happened more smoothly if they had let both python2 and python3 code coexist in the same project. The problem was forking the language like they did. Why couldn't they make the same interpreter run both python3 and python2 code, for a transition period, deprecating python2 features gradually? So you could have had legacy python2 code and new code written in python3. The low level implementation is not that different to require that big break. The only major difference was on string types, but that could have been handled. Breaking stuff as they did made no sense. And the problem is that after 10+ years that python3 came out in most Linux distribution if you type python you get python2, and it will probably ever will for maintaining compatibility with scripts that started with `#!/usr/bin/python` expecting it to be python2 and not 3. That is a problem for everyone, for maintainers of the distributions, for developer and sysadmins that cannot assume that the default version of python is 3 (you don't know how many time I wated debugging programs written by people that use Arch or whatever fancy distribution and assumed that /usr/bin/python is python3, and then the script breaks on the Debian production server...) At least since they made a new language, they could invented a new extension for the files, so the `/usr/bin/python` executable could have detected the version to use based on the extension (launch .py3 files with python3, and .py files with python2).