[Python-ideas] Migration of /usr/bin/python to python3

Barry Warsaw barry at python.org
Fri Mar 13 18:32:04 CET 2015


On Mar 13, 2015, at 05:00 AM, Bohuslav Kabrda wrote:

>+1, the system scripts should use system Python explicitly to keep working
>when user's environment changes. I'm not sure about Debian/Ubuntu, but we do
>this in Fedora as much as we can.

We do this in Debian/Ubuntu too, although it looks like there are one or two
outliers so they probably aren't built with the common Python build tools.

>And while I'm primarily a packager, I also use /usr/bin/env python[2|3] while
>coding, because it's just more handy during development.

Oh, definitely.

>For more than a year now, I've been trying to push python 3 as default in
>Fedora. "Default" means that it should be the only Python on live media/cloud
>images/... and various system applications and system scripts will run on
>it.

This is a great goal, and something that we've been working toward in
Debian/Ubuntu also.  I hope all the Linux distros can do the same thing.

>I want Fedora to follow PEP 394, so this doesn't mean switching
>/usr/bin/python to Python 3, but that's one of the biggest sources of
>confusion. Most users expect /usr/bin/python to point to "the" Python.

This is what we need to tease out I think.  For the most part, users don't
care what the shebang line of their scripts is, or even if they have one.
They *do* care about what interpreter fires up when they type `python` or any
of the variants at their shell, as well as...

>3) Custom user/sysadmin scripts pointing to /usr/bin/python

[...]

>Point 3 is the real issue, because (from my experience) there are tons of
>users/sysadmins that use Python as a shell with nice features and don't
>really care about what's going on in Python upstream. These scripts are
>outside of Python upstream and distro control and we can't do anything about
>them. My thinking is that these won't change - not now, not in two years, not
>in ten years. The only way to change them is to break them - and then the
>real question is: do we want to break them or do we want to keep them working
>forever? (well, at least until we retire Python 2, which would make
>/usr/bin/python disappear completely)

That is indeed the question.  I think if we break them, we're just pissing
people off for a not compelling enough reason (notice I didn't say "good"
reason :).

It think the first step is to strongly encourage people to start using
/usr/bin/python2 for their Python 2 scripts, and to strongly encourage all
distributions of Python to be including a 'python2' symlink.  Of course, for
anyone with even a rudimentary understanding of *nix, it's easy enough to
create that symlink if it's missing, but we might even go a step further and
include a 'fix_py2_usr_bin' script that people can run which wouldn't do
anything more than ensure /usr/bin/python2 exists.

We've committed to bug fix releases for 2.7 until 2020.  To me, that's the
time frame for any change to /usr/bin/python, whether that's complete removal
or repointing the symlink.  By then, we'll have 5 more years of educating
people to be using 'python2' and 'python3' explicitly so the impact of
resolving the ambiguity around 'python' should be lessened.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150313/859bb888/attachment-0001.sig>


More information about the Python-ideas mailing list