8 ms·

It will probably be a fair bit longer than that before 2.7 stops being relevant. 2.7 is still the default system Python on a lot of Linux distros, which will be

It will probably be a fair bit longer than that before 2.7 stops being relevant. 2.7 is still the default system Python on a lot of Linux distros, which will be in vendor support for longer. It doesn't really matter if the fixes are coming from the PSF or someone else - nice thing about Foss. RHEL/CentOS 6 is still reasonably widely used, and the system Python there is 2.6.

kstrauser 8y ago
> 2.7 is still the default system Python on a lot of Linux distros I will never understand why that matters. "ed" is the default system editor, but I'm only "{apt-get,yum} install {vim,emacs}" away from having something I actually want to use. That's the whole point of a distro. You don't have to use Python 2.ancient just because /usr/bin/paleolithic is written with it.
- jstarfish 8y ago
  Not all environments have unfettered access to the internet to download whatever arbitrary packages the user decides they need that day. Sometimes you're stuck with whatever the distro shipped with.
  - kstrauser 8y ago
    I'm not buying that excuse. It implies machines that are installed and deployed exactly once and then never updated in any way, even for security stuff. In that case, an old version of Python would be so far down the list of problems that it wouldn't even be brought up.
  - theptip 8y ago
    Most distros have been shipping Python3 for years, just not set as the target for `/usr/bin/python`. You can run `/usr/bin/python3` currently, almost anywhere. And "software that has been gradually going EOL for the last 5 years" is not "packages the user decides they need that day". I'd be very surprised if any distros that ship with Python2 do not ship with Python3 in 2020, and I'd even wager that most will default to python3 by then.
- sigjuice 8y ago
  What if you have a gigantic Python 2 codebase?
  - kstrauser 8y ago
    That's a different but unrelated problem. In that situation, consider that official support is almost over for Python 2 and extended support from third party vendors is going to get nothing but more expensive with time. It will be harder to maintain those projects as the dependencies they use drop support for an increasingly obsolete release. It will become much harder to hire great engineers willing to work on legacy versions. Basically, Python 2 is going to become a very serious technical debt very soon. It's past time to start paying that down.
  - theptip 8y ago
    You've only got 2 years, get started now! If you need to do it gradually (as would be wise for a gigantic codebase), start using `six` to make your codebase forwards-compatible. Then when all your tests pass on python3, cut over, and remove `six`. (Or take a gamble on Google taking over support for Python2 when it officially goes EOL, I suppose).
    - sigjuice 8y ago
      Redhat (or someone like them) might keep the lights on for Python 2 if a large enough customer leans on them.
      - kstrauser 8y ago
        There's approximately zero chance that RedHat will support backports of huge, many-contributor projects like NumPy or Django that are dropping Python 2 support (see: https://docs.scipy.org/doc/numpy/neps/dropping-python2.7-proposal.html https://docs.scipy.org/doc/numpy/neps/dropping-python2.7-pro... and https://docs.djangoproject.com/en/2.0/releases/2.0/ https://docs.djangoproject.com/en/2.0/releases/2.0/). They just can't - there aren't enough hours in the day. Five years from how, you don't want to be explaining to your CEO why it's literally impossible for you to integrate with a third party SDK because your stack is so ancient and petrified that new code can't incorporate it.
- zenhack 8y ago
  In this context it doesn't really matter that it's the "default", just that it's supported by the distro maintainers, and so receiving security updates regardless of what the PSF supports.

kstrauser 8y ago

> 2.7 is still the default system Python on a lot of Linux distros I will never understand why that matters. "ed" is the default system editor, but I'm only "{apt-get,yum} install {vim,emacs}" away from having something I actually want to use. That's the whole point of a distro. You don't have to use Python 2.ancient just because /usr/bin/paleolithic is written with it.

jstarfish 8y ago
Not all environments have unfettered access to the internet to download whatever arbitrary packages the user decides they need that day. Sometimes you're stuck with whatever the distro shipped with.
- kstrauser 8y ago
  I'm not buying that excuse. It implies machines that are installed and deployed exactly once and then never updated in any way, even for security stuff. In that case, an old version of Python would be so far down the list of problems that it wouldn't even be brought up.
- theptip 8y ago
  Most distros have been shipping Python3 for years, just not set as the target for `/usr/bin/python`. You can run `/usr/bin/python3` currently, almost anywhere. And "software that has been gradually going EOL for the last 5 years" is not "packages the user decides they need that day". I'd be very surprised if any distros that ship with Python2 do not ship with Python3 in 2020, and I'd even wager that most will default to python3 by then.
sigjuice 8y ago
What if you have a gigantic Python 2 codebase?
- kstrauser 8y ago
  That's a different but unrelated problem. In that situation, consider that official support is almost over for Python 2 and extended support from third party vendors is going to get nothing but more expensive with time. It will be harder to maintain those projects as the dependencies they use drop support for an increasingly obsolete release. It will become much harder to hire great engineers willing to work on legacy versions. Basically, Python 2 is going to become a very serious technical debt very soon. It's past time to start paying that down.
- theptip 8y ago
  You've only got 2 years, get started now! If you need to do it gradually (as would be wise for a gigantic codebase), start using `six` to make your codebase forwards-compatible. Then when all your tests pass on python3, cut over, and remove `six`. (Or take a gamble on Google taking over support for Python2 when it officially goes EOL, I suppose).
  - sigjuice 8y ago
    Redhat (or someone like them) might keep the lights on for Python 2 if a large enough customer leans on them.
    - kstrauser 8y ago
      There's approximately zero chance that RedHat will support backports of huge, many-contributor projects like NumPy or Django that are dropping Python 2 support (see: https://docs.scipy.org/doc/numpy/neps/dropping-python2.7-proposal.html https://docs.scipy.org/doc/numpy/neps/dropping-python2.7-pro... and https://docs.djangoproject.com/en/2.0/releases/2.0/ https://docs.djangoproject.com/en/2.0/releases/2.0/). They just can't - there aren't enough hours in the day. Five years from how, you don't want to be explaining to your CEO why it's literally impossible for you to integrate with a third party SDK because your stack is so ancient and petrified that new code can't incorporate it.
zenhack 8y ago
In this context it doesn't really matter that it's the "default", just that it's supported by the distro maintainers, and so receiving security updates regardless of what the PSF supports.