7 ms·

Guido van Rossum: Python 2 end-of-life will be on January 1st, 2020

91 points by bakery2k 9y ago

mattbillenstein 9y ago
As a Python2 holdout, I'm glad they extended the EOL -- and I'm actually glad I held out this long, starting some python3 stuff now and things work -- libs and tools that I'm used to in python2 seem all there in python3.
- dfee 9y ago
  If you don’t continue to hold out, who will? And, if you move on, are we losing access to living history?
  - mattbillenstein 9y ago
    What do you mean? Python2 history I see as preserved in the cpython repo, mailing lists, etc. Python3 has enough improvements in the CPython VM to warrant upgrading at this point.
  - oliwarner 9y ago
    Let's maintain every version of everything ever made, forever. Won't somebody please think of the children! But if that wasn't sarcasm, nobody's removing "access" to this historical artefact. Python 2's source code is available as long as somebody stores it. But the resources required to keep it secure are needed elsewhere. If you simply want to preserve it, talk to an archivist. The Python community has moved on.
    - dfee 9y ago
      It was sarcasm!
      - mattbillenstein 9y ago
        Please use <sarcasm>Something sarcastic</sarcasm> as appropriate ;)
- malcolmgreaves 9y ago
  Why are you a Python 2 holdout? What are you holding out for?
  - mattbillenstein 9y ago
    Early adopters are beta testers ;) I think until about 2014 (3.4) Python 3 just wasn't really ready. Then maybe it took another two years for library and tooling support to firm up around that. In 2016 I did start a new project, but a mix of familiarity and gevent support kept me on 2.7. Also, until recently the runtime had no real advantage over 2.7, but there have been some incremental improvements (dict shared keys and so forth) that are a win you get in Python 3 for free basically. Working on a new project in 3.6 now and it's looking good so far.
nineteen999 9y ago
I note RHEL 7.x still contains Python 2 as the default, with Python 3 available from EPEL. But you can't remove Python 2 since just about everything in the system (including the package manager) depends on the Python 2. RHEL7 is not due to be EOL until 2024, so Redhat (and others) will be holding the baby for a long time after 2020.
- jlgaddis 9y ago
  The end of "full support" for RHEL 7 is "~Q4 of 2019". After that, there's "Maintenance Support" until 30 Jun 2024 but that only includes "errata", which are "provided at Red Hat's discretion" -- and specifically excludes "Software Enhancements" ("additions of new functionality beyond correcting defects ..."). I expect that after Python 2's EOL, we'll see very little in the way of updates for RHEL 7's Python 2 packages. There just won't be that much for them to do.
  - nineteen999 9y ago
    It's referred to as Extended Update Support (EUS). Of course nobody is expecting any enhancements beyond 2019 but for long-lived critical infrastructure projects (eg. mine) any critical security fixes will be required - for my project in particular at least until 2022.
deleted 9y ago
[deleted]
kbaker 9y ago
The 'wall of superpowers' looks much better than last time I looked. Almost all done! https://python3wos.appspot.com/ https://python3wos.appspot.com/
- thinkpad20 9y ago
  That list was a little surprising to me. Simplejson at the top, a library I’ve never used which seems to be obviated by the presence of json in the standard library (similarly argparse). Surprised to see pymongo above Flask. Also surprised to see Django having 10m more downloads than Flask.
  - coldtea 9y ago
    >Simplejson at the top, a library I’ve never used which seems to be obviated by the presence of json in the standard library json and simplejson are the same modules. It's just that json is based on an older version of simplejson, since the latter is not tied to the Python release cycles, and updates faster. Simplejson also works with older pythons that didn't have json built-in (2.4 etc). People using it is not about needing a JSON because there isn't one in the standard library, it's because it was faster than it. 2 times faster loading, and somewhat faster dumping (depending on json and simplejson version). >* Also surprised to see Django having 10m more downloads than Flask.* Django is much older and more established. When Flask was still a new thing, Django had several versions out and people using it.
    - HankB99 9y ago
      Does having the package available for 3.x facilitate code migration? Would the references to the builtin in 3.x require other code mods (or just the import statement?)
      - coldtea 9y ago
        Not very familiar (mostly using 2.7 atm), but I think simplejson should be a drop-in replacement to the built-in, and as such shouldn't affect code migration.
Silhouette 9y ago
I wish we had a better term for this sort of event than "end of life". It's perfectly reasonable for the team who are the primary developers of Python 2 to say they want to move on and they aren't going to release any more updates after some specific date. After all, it's not as if most of us are paying them for their hard work, appreciated though it is. On the other hand, it's also not as if Python 2 will suddenly stop working on 1 January 2020. The interpreter on my server will still run, and so will the scripts that have been using it for many years and have no reason to change because they're still doing a useful job. The situation with purely locally-installed software it typically quite different to the situation with software that depends on some remote service or runs on someone else's server and is accessed via a web or mobile UI, where the developers can literally just turn it off and users immediately lose the ability to run some or all of it. I think we should be more careful about making this distinction.
- oliwarner 9y ago
  > no reason to change because they're still doing a useful job Sure, but keeping it compatible with your OS —when it receives updates— is on you. Backporting security patches from Python 3, 4, 5 etc are on you. I'll grant you, if you're running an air-gapped machine with no keyboard, ports or basically any external IO, you probably needn't worry too much about security. But that would put you in 0.0000000001% of deployments. Everybody else should treat unmaintained Python 2 interpreters as dangerous zombies that need putting out of their misery. They're potentially vulnerable to whoknowswhat and past 2020 CPython isn't getting any fixes. If there's any vector into your system, it's a big fat target, and if vulnerable, a gateway into the rest the system/network/etc. Python 2 is on life support. They're pulling the plug on 2020-01-01. You can choose to keep a zombie lurching around or you can give it a good death.
  - Chris2048 9y ago
    Who is they though? Why can't a community grow around python2?
    - oliwarner 9y ago
zyx321 9y ago
Python 2, Windows 7, Adobe Flash. Early 2020 is shaping up to be a bloodbath.

91 points by bakery2k 9y ago

As a Python2 holdout, I'm glad they extended the EOL -- and I'm actually glad I held out this long, starting some python3 stuff now and things work -- libs and tools that I'm used to in python2 seem all there in python3.

dfee 9y ago
If you don’t continue to hold out, who will? And, if you move on, are we losing access to living history?
- mattbillenstein 9y ago
  What do you mean? Python2 history I see as preserved in the cpython repo, mailing lists, etc. Python3 has enough improvements in the CPython VM to warrant upgrading at this point.
- oliwarner 9y ago
  Let's maintain every version of everything ever made, forever. Won't somebody please think of the children! But if that wasn't sarcasm, nobody's removing "access" to this historical artefact. Python 2's source code is available as long as somebody stores it. But the resources required to keep it secure are needed elsewhere. If you simply want to preserve it, talk to an archivist. The Python community has moved on.
  - dfee 9y ago
    It was sarcasm!
    - mattbillenstein 9y ago
      Please use <sarcasm>Something sarcastic</sarcasm> as appropriate ;)
malcolmgreaves 9y ago
Why are you a Python 2 holdout? What are you holding out for?
- mattbillenstein 9y ago
  Early adopters are beta testers ;) I think until about 2014 (3.4) Python 3 just wasn't really ready. Then maybe it took another two years for library and tooling support to firm up around that. In 2016 I did start a new project, but a mix of familiarity and gevent support kept me on 2.7. Also, until recently the runtime had no real advantage over 2.7, but there have been some incremental improvements (dict shared keys and so forth) that are a win you get in Python 3 for free basically. Working on a new project in 3.6 now and it's looking good so far.

nineteen999 9y ago

I note RHEL 7.x still contains Python 2 as the default, with Python 3 available from EPEL. But you can't remove Python 2 since just about everything in the system (including the package manager) depends on the Python 2. RHEL7 is not due to be EOL until 2024, so Redhat (and others) will be holding the baby for a long time after 2020.

jlgaddis 9y ago
The end of "full support" for RHEL 7 is "~Q4 of 2019". After that, there's "Maintenance Support" until 30 Jun 2024 but that only includes "errata", which are "provided at Red Hat's discretion" -- and specifically excludes "Software Enhancements" ("additions of new functionality beyond correcting defects ..."). I expect that after Python 2's EOL, we'll see very little in the way of updates for RHEL 7's Python 2 packages. There just won't be that much for them to do.
- nineteen999 9y ago
  It's referred to as Extended Update Support (EUS). Of course nobody is expecting any enhancements beyond 2019 but for long-lived critical infrastructure projects (eg. mine) any critical security fixes will be required - for my project in particular at least until 2022.

deleted 9y ago

[deleted]

kbaker 9y ago

The 'wall of superpowers' looks much better than last time I looked. Almost all done! https://python3wos.appspot.com/ https://python3wos.appspot.com/

thinkpad20 9y ago
That list was a little surprising to me. Simplejson at the top, a library I’ve never used which seems to be obviated by the presence of json in the standard library (similarly argparse). Surprised to see pymongo above Flask. Also surprised to see Django having 10m more downloads than Flask.
- coldtea 9y ago
  >Simplejson at the top, a library I’ve never used which seems to be obviated by the presence of json in the standard library json and simplejson are the same modules. It's just that json is based on an older version of simplejson, since the latter is not tied to the Python release cycles, and updates faster. Simplejson also works with older pythons that didn't have json built-in (2.4 etc). People using it is not about needing a JSON because there isn't one in the standard library, it's because it was faster than it. 2 times faster loading, and somewhat faster dumping (depending on json and simplejson version). >* Also surprised to see Django having 10m more downloads than Flask.* Django is much older and more established. When Flask was still a new thing, Django had several versions out and people using it.
  - HankB99 9y ago
    Does having the package available for 3.x facilitate code migration? Would the references to the builtin in 3.x require other code mods (or just the import statement?)
    - coldtea 9y ago
      Not very familiar (mostly using 2.7 atm), but I think simplejson should be a drop-in replacement to the built-in, and as such shouldn't affect code migration.

Silhouette 9y ago

I wish we had a better term for this sort of event than "end of life". It's perfectly reasonable for the team who are the primary developers of Python 2 to say they want to move on and they aren't going to release any more updates after some specific date. After all, it's not as if most of us are paying them for their hard work, appreciated though it is. On the other hand, it's also not as if Python 2 will suddenly stop working on 1 January 2020. The interpreter on my server will still run, and so will the scripts that have been using it for many years and have no reason to change because they're still doing a useful job. The situation with purely locally-installed software it typically quite different to the situation with software that depends on some remote service or runs on someone else's server and is accessed via a web or mobile UI, where the developers can literally just turn it off and users immediately lose the ability to run some or all of it. I think we should be more careful about making this distinction.

oliwarner 9y ago
> no reason to change because they're still doing a useful job Sure, but keeping it compatible with your OS —when it receives updates— is on you. Backporting security patches from Python 3, 4, 5 etc are on you. I'll grant you, if you're running an air-gapped machine with no keyboard, ports or basically any external IO, you probably needn't worry too much about security. But that would put you in 0.0000000001% of deployments. Everybody else should treat unmaintained Python 2 interpreters as dangerous zombies that need putting out of their misery. They're potentially vulnerable to whoknowswhat and past 2020 CPython isn't getting any fixes. If there's any vector into your system, it's a big fat target, and if vulnerable, a gateway into the rest the system/network/etc. Python 2 is on life support. They're pulling the plug on 2020-01-01. You can choose to keep a zombie lurching around or you can give it a good death.
- Chris2048 9y ago
  Who is they though? Why can't a community grow around python2?
  - oliwarner 9y ago

zyx321 9y ago

Python 2, Windows 7, Adobe Flash. Early 2020 is shaping up to be a bloodbath.