The default for Debian [0] and Ubuntu [1] is Python3. The `/usr/bin/python` symlink will be Python2 forever, since Python itself advises it. PEP 394[2]:

> for the time being, all distributions should ensure that python refers to the same target as python2.

[0] https://www.debian.org/doc/packaging-manuals/python-policy/c... [1] https://blueprints.launchpad.net/ubuntu/+spec/core-1311-pyth... [2] https://www.python.org/dev/peps/pep-0394/

Am I incorrect in recalling that ArchLinux decided against this?

edit: seems to be the case[0]

[0]: https://wiki.archlinux.org/index.php/python#Python_2

Read the next line in PEP 394 ;)

> however, end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP), so python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3.

Yes, which is why it is a staple of PKGBUILDs for Python software to do

  sed -i s/python/python3/ /all/the/things

Before upstream CPython had any defined policy on the python symlink.

All major distributions have completed their switch to Python 3 or ship it already.

This is Canonical's stance:

> All Ubuntu/Canonical driven development should be targeting Python 3 right now, and all new code should be Python 3-only.

Regardless, nowadays many people deploy Python applications as stand-alone bundles. We're happily running Python 3.5 on CentOS 6 and it took like ten minutes to deploy (pyenv!). This lets us use a rock-solid base system with an up-to-date application stack, which makes our old school admins happy.

Hmm, ok so you suggest all of a sudden switching to explicitly calling Python 2 with python2, like it is now for Python 3? Python 3 is present and working by default but we just decide, by convention, that Python 2 = python and Python 3 is python3. For obvious backwards and horizontal compatibility.

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:    Ubuntu 16.04.1 LTS
  Release:        16.04
  Codename:       xenial

  $python3 --version
  Python 3.5.2

Edit: Just to check I started a clean 16.04 (on DO) and did the commands:

  # lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:    Ubuntu 16.04.1 LTS
  Release:        16.04
  Codename:       xenial

  # python --version
  The program 'python' can be found in the following packages:
   * python-minimal
   * python3
  Try: apt install <selected package>

  # python3 --version
  Python 3.5.2

So, no python 2 by default but python 3 and you call it using "python3" as adviced in the pep qznc talks about.

Afaik, it has nothing to do with Ubuntu or any other Linux distro specifically, but this is rather a choice from python itself. See PEP394 [1]:

"for the time being, all distributions should ensure that python refers to the same target as python2."

I read above as the python community itself made "python" the default for python 2.7 and "python3" for python 3.x. Nevertheless, an unfortunate choice at this time. I understand the reasoning at the time of writing (March 2011) but now this should be reconsidered.

    [1] https://www.python.org/dev/peps/pep-0394/

We actually hit an unfortunate consequence of this with some scripts being called in python 2 mode while we were working in a python 3 virtual environment.

Hmm... you really use the system Python installation for development? Python is not pathologically backwards compatible, what happens when the next OS version use a newer Python 2 version?

You don't simply upgrade your production machines to the next OS version with fingers crossed. You do some testing and validation first.

Say, you use containers and so your application is isolated from the host system. When the next version of your host system comes with a new version of Docker, you have to do similar testing and validation anyway.

Personally? I don't, I use Python 3 and virtualenvs but then everything I write in Python is for myself to do things for me.

If I was writing software that had to be used in as many places as possible or sold, I'd absolutely strongly consider using 2.7.

OS vendors have similar issues with other open source projects. They tend to ship versions which are years out of date.

I understand the desire to have stable releases. But... if you're not shipping the most recent stable version of something, and instead shipping something that's 4-5 years old... it's frustrating for users and developers alike.