[Python-Dev] Python 3 as a Default in Linux Distros

[Barry Warsaw]

On Jul 24, 2013, at 05:12 AM, Bohuslav Kabrda wrote:

>in recent days, there has been a discussion on fedora-devel (see thread [1])
>about moving to Python 3 as a default.

I've been lurking via Gmane. :)

>- Should we point /usr/bin/python to Python 3 when we make the move?

Over in Debian (inherited by Ubuntu), we have no plans to do this.  Currently,
/usr/bin/python points to pythonX.Y which for us is 2.7.  Our /usr/bin/python2
symlink also points to python2.7, and our /usr/bin/python3 points to python3.3.

I'm very much in favor of promoting Python 3 adoption through the entire
ecosystem.  We've been working in Ubuntu to banish Python 2 off the images,
eventually only in universe by the next LTS (14.04 - in April 2014).  For
practical reasons, I don't think we'll quite get there, but it's good to have
goals, and I've been really impressed with the progress made by distro
developers and upstreams.

"Porting is one honking great idea -- let's do more of those!"

We have a mandate that all new work (certainly where Canonical is the upstream
for Ubuntu packages) should be Python 3 unless there are specific dependencies
for which porting is impractical and there are no alternatives.  We want no
Python 2 on the Ubuntu Touch images.  Some of the new work will retain Python
2 compatibility for now, again for practical reasons.

Code we control is the easy part.  There is just so much out there that isn't
even in the distro, stuff that no distro maintainer will ever even know about
(unless we break stuff ;), and all of that is expecting /usr/bin/python to be
Python 2.  If they want Python 3, they are explicitly shebanging
/usr/bin/python3.  I think Nick in one of the Fedora threads correctly
identified the vast number of one-off scripts out there.

At this time, I think keeping /usr/bin/python pointing to Python 2 (2.7
preferably) strikes the right balance between what we in Python land would
like to see happen, with the least amount of pain, and friendly encouragement
to our distro users.

I hope someday we can remember Python 2 as fondly as we remember 1.5.2
(<cough>1.6.1</cough>).  I think there's a ton of things we can do to get us
there, but forcing our users through unnecessary pain too early won't help the
cause.  The last year or so has really shown a very positive shift toward
Python 3, in code, mindshare, and enthusiasm.

>I know that pep 394 [2] deals with this and it says that /usr/bin/python may
>refer to Python 3 on some bleeding edge distributions - supposedly, this was
>added to the pep because of what Arch Linux did, not the other way round.

Correct.  I think we should consider rewording the text to make this more
clear.

>As the pep says, the recommendation of pointing /usr/bin/python to Python 2
>may be changed after the Python 3 ecosystem is sufficiently mature. I'm
>wondering if there are any more specific criteria - list of big projects
>migrated/ported or something like that - or will this be judged by what I'd
>call "overall spirit" in Python community (I hope you know what I mean by
>this)?

In the discussions I've had at Pycon and various other forum, it seems like
Python 2.7's scheduled security-only transition in May 2015 would be an
appropriate time to make the switch.  If there's broad agreement to do this,
we have plenty of time to prepare our users, and all of our software stacks.

>- What should user get after using "yum install python"?

I can only say that for Debian and Ubuntu, `apt-get install python` will get
you the default Python 2 version (e.g. 2.7).  `apt-get install python3` will
get you the default Python 3 version (e.g. 3.3).  I don't think changing this
really provides much user benefit, and I've not seen any complaints/bugs
indicating user confusion or frustration.  I'd advocate for being user driven
here, i.e. IIABDFI[1].

>All of the approaches have their pros and cons, but generally it is all about
>what user should get when he tries to install python - either nothing or
>python2 for now and python3 in future - and how we as a distro cope with that
>on the technical side (and when we should actually do the switch).

I'm glad Arch is out there hacking at the vines.  For whatever part I can play
and for whatever my opinion matters, I would like to keep the Fedora/RH and
Debian/Ubuntu ecosystem in sync.  PEP 394 is the instrument we should rally
around.

Cheers,
-Barry

[1] The secret 20th Zen of Python?  If It Ain't Broke Don't Fix It.