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

[Toshio Kuratomi]

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).

<nod>  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:

* python should refer to the same target as python2 but may refer to python3
on some bleeding edge distributions

Knowing the history, I read this in two parts:
* Recommendation to distributions: "python should refer to the same target
  as python2".
* Statement of fact: "but may refer to python3 on some bleeding edge
  *ahem*Arch*ahem* distributions"

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.

<nod>  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>