[Python-Dev] Python 3 as a Default in Linux Distros (original) (raw)

Toshio Kuratomi a.badger at gmail.com
Wed Jul 24 17:26:44 CEST 2013

Note: I'm the opposite number to bkabrda in the discussion on the Fedora Lists about how quickly we should be breaking end-user expectations of what "python" means.

On Wed, Jul 24, 2013 at 09:34:11AM -0400, Brett Cannon wrote:

On Wed, Jul 24, 2013 at 5:12 AM, Bohuslav Kabrda <bkabrda at redhat.com> wrote: Hi all, in recent days, there has been a discussion on fedora-devel (see thread [1]) about moving to Python 3 as a default. I'd really love to hear opinions on the matter from the upstream, mainly regarding these two points (that are not that clearly defined in my original proposal and have been formed during the discussion): Note that the proposal is for Fedora 22. So the timeframe for making the switch in development is approximately 8 months from now. Timeframe for that release to be public is October 2014.

- Should we point /usr/bin/python to Python 3 when we make the move? 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. 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 Fedora, we have two concerns that clash in this decision - being "First" (e.g. actively promote and use new technologies and also suggest them to our users) vs. not breaking user expectations. So we figured it'd be a good idea to ask upstream to get more opinions on this.

- What should user get after using "yum install python"? There are basically few ways of coping with this: 1) Just keep doing what we do, eventually far in the future drop "python" package and never provide it again (= go on only with python3/python4/... while having "yum install python" do nothing). 2) Do what is in 1), but when "python" is dropped, use virtual provide (*) "python" for python3 package, so that "yum install python" installs python3. 3), 4) Rename python to python2 and {don't add, add} virtual provide "python" in the same way that is in 1), 2) 4) Is my preference: python package becomes python2; Virtual Provide: python means you'd get the python package is what I'd promote for now. Users still expect python2 when they talk about "python". At some point in the future, people will come to pycon and talks will apply to python3 unless otherwise specified. People writing new blog posts will say "python" and the code they use as samples won't run on the python2 interpreter. Expecting for that to be the case in 12 months seems premature.

5) Rename python to python2 and python3 to python at one point. This makes sense to me from the traditional "one version in distro + possibly compat package shipping the old" approach in Linux, but some say that Python 2 and Python 3 are just different languages [3] and this should never be done. 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). Just as a sidenote, IMO the package that gets installed as "python" (if any) should point to /usr/bin/python, which makes consider these two points very closely coupled.

A similar discussion broke out when Arch Linux switched python to point to python3. This led to http://www.python.org/dev/peps/pep-0394/ which says have python2/python3, and have python point at whatever makes the most sense to you based on your users and version uptake (option 3/4).

I think bkabrda is looking for some clarification on PEP-394. My reading and participation in the previous discussions lead me to believe that while PEP-394 wants to be diplomatic, the message it wants to get across is:

  1. warn distributions that what Arch was doing was premature.
  2. provide a means to get them to switch at roughly the same time (when the recommendation in the PEP is flipped to suggest linking /usr/bin/python to /usr/bin/python3)

This is especially my reading from the Recommendations section of the PEP. Unfortunately, we're getting stuck in the Abstract section which has this bullet point:

Knowing the history, I read this in two parts:

However, other people are reading this as one recommendation for distributions:

If you are a conservative, slow moving distro (like RHEL or Debian Stable) then you should point to python2. If you are a fast moving distro like Arch or Fedora or Ubuntu then you should point to python3.

So -- is there some opinion on which of these is correct?

The key, though, is adding python2 and getting your code to use that binary  specifically so that shifting the default name is more of a convenience than something which might break existing code not ready for the switch.

yeah, this is something that I think should be in the distribution's one year plan regardless of whether the binary is switched now or not. Note that I (and from Nick's last email on the fedora thread, I think he would agree) consider this a prerequisite but not the primary gating factor for shifting /usr/bin/python to point to /usr/bin/python3. In addition to the applications managed by the distribution there's also the mass of local scripts written for each site that will break if the interpreter is switched.

I proposed above some of the things that would indicate user expectation has switched and make it appropriate to break scripts that haven't ported (because those users and admins would look at the world around them and see that they were overdue on changing their expectation that python meant python2 instead of python3.) Barry Warsaw, on IRC, also proposed that letting the upstream python core team make the decision by switching at the distribution level when the core team switched the recommendation in PEP-394 made sense and I can agree with that as well.

-Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20130724/d4e732e0/attachment.pgp>

More information about the Python-Dev mailing list