6 ms·

http://i.imgur.com/EJM1viF.png http://i.imgur.com/EJM1viF.png That's why Python 2.7 will be around and maintain dominance for a while. When the latest stable

http://i.imgur.com/EJM1viF.png http://i.imgur.com/EJM1viF.png That's why Python 2.7 will be around and maintain dominance for a while. When the latest stable releases of the primary environments are defaulting to something you have to have very good reasons why not to use the default (even when it's easy to change the default). Administrators (in the old school not the new "everything in containers") don't like using non-defaults.

berntb 10y ago
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?
- noir_lord 10y ago
  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.
- cuu508 10y ago
  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.
juriansluiman 10y ago
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/
- rtpg 10y ago
  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.
teekert 10y ago
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.
qznc 10y ago
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/ch-python3.html https://www.debian.org/doc/packaging-manuals/python-policy/c... [1] https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap https://blueprints.launchpad.net/ubuntu/+spec/core-1311-pyth... [2] https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/
- deleted 10y ago
  [deleted]
- oneweekwonder 10y ago
  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 https://wiki.archlinux.org/index.php/python#Python_2
  - gsnedders 10y ago
    Before upstream CPython had any defined policy on the python symlink.
  - majewsky 10y ago
    Yes, which is why it is a staple of PKGBUILDs for Python software to do sed -i s/python/python3/ /all/the/things
  - qznc 10y ago
    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.
eeZi 10y ago
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.
adekok 10y ago
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.

berntb 10y ago

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?

noir_lord 10y ago
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.
cuu508 10y ago
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.

juriansluiman 10y ago

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/

rtpg 10y ago
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.

teekert 10y ago

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.

qznc 10y ago

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/ch-python3.html https://www.debian.org/doc/packaging-manuals/python-policy/c... [1] https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap https://blueprints.launchpad.net/ubuntu/+spec/core-1311-pyth... [2] https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/

deleted 10y ago
[deleted]
oneweekwonder 10y ago
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 https://wiki.archlinux.org/index.php/python#Python_2
- gsnedders 10y ago
  Before upstream CPython had any defined policy on the python symlink.
- majewsky 10y ago
  Yes, which is why it is a staple of PKGBUILDs for Python software to do sed -i s/python/python3/ /all/the/things
- qznc 10y ago
  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.

eeZi 10y ago

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.

adekok 10y ago

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.