On Tue, 8 Aug 2017, Ben Finney wrote:
The issue is: Invoking ‘python’ today gets an interpereter, Python 2, that will work with some code and not others. It should not tomorrow invoke an incompatible interpreter without *knowing* that the vast majority of scripts in the wild no longer expect Python 2 to come from that command. That day might never come, in which case the ‘python’ command will forever mean Python 2. That is, I'm saying, better than breaking that command in the near or medium future. I'm saying it's a bad idea for ‘python’ tomorrow to get an incompatible intepreter that won't run the same Python code. That interpreter is named ‘python3’ and should never be installed as ‘python’, because ‘python’ is a command that many scripts expect to invoke Python 2.
This conflates the role of the interactive Python interpreter (which is what Diane was referring to) and a script interpreter. #!/usr/bin/python and `python -c` are ABI referring to Python 2, yes, and can't start running Python 3 any more than /lib/libc.so.5 can start being glibc. But there's no reason this should prevent typing "python" from giving you a Python 3 interpreter.
Since I think it hasn't been linked recently on this list, I'll re-link this project, which separates the two roles:
https://github.com/geofft/pythonmux
https://ldpreload.com/blog/usr-bin-python-23
Keep in mind that we do intend to break the ability for /usr/bin/python to
run Python 2 code in less than three years (unless we're interested in
providing security support for Python 2 when it's dead upstream, which I
hope nobody wants to do). We will not indefinitely provide a
/usr/bin/python that runs Python 2; we probably will do so for at most one
more stable release.
The only question is whether it should break by giving you an error message (either ENOENT or something printed on stderr), or break by trying to run the code as Python 3.
-- Geoffrey Thomas https://ldpreload.com geofft@ldpreload.com