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
geo...@ldpreload.com
