Re: Python Policy: Things to consider for Stretch
Thanks for taking this on Ben,
On Jan 24, 2016, at 04:33 PM, Ben Finney wrote:
>I think you're right that this needs a general clean-up through the
>policy document, to consistently use:
>
>* “python2” to refer to that command only;
>
>* “python3” to refer to that command only;
>
>* “python” to refer to that command (and I'd suggest deprecating it
> where feasible);
>
>* “Python 2” referring exclusively to that language version 2.x and no
> other versions of that language;
>
>* “Python 3” referring exclusively to that language version 3.x and no
> other versions of that language;
>
>* “Python” referring to the language implemented either as Python 2 or
> Python 3.
I agree with all the above, though re: Scott's feedback on deprecation of
/usr/bin/python, here's my take (note, we've had these discussions many times
before ;).
Ultimately, we should be both guided by, and drive with our opinions, PEP 394
which should help keep the situation consistent across *nix distros.
https://www.python.org/dev/peps/pep-0394/
/usr/bin/python (on Debian) should never point to anything but the latest
Python 2 version *until* Python 2.7 is EOL'd upstream, meaning binary, source,
and security-only releases. Bug fix releases (source only) are promised until
2020, and I'd wager we'll see supported security-only releases until 2025.
I would like to see scripts that are only compatible with Python 2 to be
shebanged `/usr/bin/python2` or `/usr/bin/python2.7`. You can think of this
mostly as documentation at this point, but it does remove any possibility of
future ambiguity.
It also begins to open the door to the often discussed launcher idea someday
landing on /usr/bin/python, enabling bilingual scripts.
I think there's zero harm in this since shebang lines are generally not
user-evident.
Then there's no change to /usr/bin/python any time soon, or the fact that
invoking `python` at the shell starts the Python 2 interpreter.
Cheers,
-Barry
Reply to: