12 ms·

NumPy 1.16 is the last release to support Python 2.7

240 points by htfy96 8y ago

oriol11 8y ago
"Numpy 1.16 is good enough" - Me in 2029
- tinus_hn 8y ago
  Clinging on to the past for dear life..
  - coldtea 8y ago
    Or, if it ain't broken, don't fix it.
    - tinus_hn 8y ago
      Well, it’s open-source so you’re free to volunteer your resources and maintain it yourself
      - coldtea 8y ago
        Well, it's dependent upon by lots of huge companies, so I'm sure it will forked and maintained anyway well beyond 2020... Strongly wishing things to die doesn't make it so...
        tinus_hn 8y ago
        Great, so everyone’s happy!
lykr0n 8y ago
Just rip the band-aid off. Some of the async stuff in Python 3 is awesome. A bit curious that 3.4 has been dropped, as that's the stock Python 3 shipped for CentOS 7.
- gammateam 8y ago
  Debian also does not have anything above python 3.4 on the stable packages branch 3.6 has been dev and test since 2016
  - lykr0n 8y ago
    It's not very clear, but this release is last release supporting 2.7 & 3.4. 1.5.6 supports 3.4.
    - Thorrez 8y ago
      I don't understand your comment. Version 1.5.6 of what? The NumPy 1.16.0 notes say > Support for Python 3.4 been dropped, the supported Python versions are 2.7 and 3.5-3.7. That definitely sounds like NumPy 1.16.0 doesn't support python 3.4.
  - mehrdadn 8y ago
    Why in the world is Debian like this? Their buggy latexmk is also from 2015. Somehow I feel like every system that I want to keep updated stays on an old version, and every system that I want to keep pinned to some version just force-feeds me its updates...
    - geofft 8y ago
      Because it's the stable branch, and it gets no major version updates for anything after release, nor any new packages, just bugfixes to the current version. There is backports, and I've thought about maintaining a newer Python interpreter in backports (when I was working for a company using Jessie and trying to use a Debian stack for everything and sort of wanting async syntax). You could introduce python3.6 or python3.7 as a new package in backports. But it would be extremely hard to update the Python modules in Debian to the newer version, too, because there's just a "python3-foo" package for each module, so you'd either have to recompile all binary modules and patch them to work on the newer Python as necessary (and patch anything using async or await as regular identifiers....), or you'd have to introduce an interpreter that intentionally wasn't compatible with modules installed as Debian packages. (Or you could introduce an interpreter that tried its best and failed randomly, which seems worse than either option.) I'm personally sympathetic to wanting to get /usr/bin/python3.6 from my OS even if the only useful thing to do is put a virtualenv on top, but I think it makes sense to just install Python yourself into /usr/local at that point. Re latexmk, it looks like the volunteer maintainer hasn't updated it since 2015, and there's a culture of not stepping on people's toes and waiting a while before assuming they're inactive or no longer care. But it's been updated in the development release. The current changelog https://metadata.ftp-master.debian.org/changelogs/main/l/latexmk/latexmk_4.61-0.1_changelog https://metadata.ftp-master.debian.org/changelogs/main/l/lat... has a bunch of "NMU" entries, non-maintainer uploads.
anonymousCar 8y ago
When can we start calling Python 2.7 legacy code?
- ggm 8y ago
  Now. seriously. I think we have to treat it as legacy code now.
- gnulinux 8y ago
  EDIT: My comment is grossly misunderstood and I cannot delete my comment. I did not imply python 3 causes bad code, I was trying to tell a story about how "our" python 2 code is handsome and python 3 code is ugly; sorta implying python2 is not necessarily legacy code. I have absolutely no problem with python 3 and prefer it over python 2. I do not want to start a 2 vs 3 flamewar please just ignore this comment. === My company has >1 million line of python 2.7. About 1.5 year ago we managed to pass our test harness (about 80% line coverage) in python 3. At the moment we can't do that but we believe if we tried hard for a few weeks we can do it again too. I don't know how we define "legacy code" but I code in this codebase everyday and the code is actually very pretty and understandable. We also have a python 3 project (only a few thousand line of code) and god that code is definitely ugly as shit. Even after python2 goes unmaintained, I will still think our python3 code looks more like legacy.
  - nas 8y ago
    If your Python 2 code is clean and your Python 3 is ugly, I don't know what the hell you are doing. They are almost the same language. Are you trolling?
    - S4M 8y ago
      Probably the Python 3 code was rushed and/or written by an inexperienced programmer. That would just be a coincidence, nothing to do with Python 2 or 3.
    - ovi256 8y ago
      The narcissism of small differences: it makes us notice differences (and dislike the differences) between things that are mostly identical to outside observers.
James_Owens_69 8y ago
Nope. Python 2.7 is and will continue to be used in scientific labs. Nobody will upgrade their working scripts.
sbrother 8y ago
The only thing keeping me on Python 2.7 is Apache Beam, but it's becoming increasingly painful and I'm close to just using a different technology rather than deal with making all my code py2 compatible in 2019...
- rasmi 8y ago
  For those interested, you can track Beam Python 3 support progress here: https://issues.apache.org/jira/browse/BEAM-1251 https://issues.apache.org/jira/browse/BEAM-1251
deleted 8y ago
[deleted]
MichaelMoser123 8y ago
Right now I don't think that python2.7 is very well supported in 1.16. Had to build a docker the other day that uses python2.7 and while building the docker it got numpy 1.16 from the pip mirror. Now import of numpy failed so that I had to revert to the previous version of numpy.

240 points by htfy96 8y ago

oriol11 8y ago

"Numpy 1.16 is good enough" - Me in 2029

tinus_hn 8y ago
Clinging on to the past for dear life..
- coldtea 8y ago
  Or, if it ain't broken, don't fix it.
  - tinus_hn 8y ago
    Well, it’s open-source so you’re free to volunteer your resources and maintain it yourself
    - coldtea 8y ago
      Well, it's dependent upon by lots of huge companies, so I'm sure it will forked and maintained anyway well beyond 2020... Strongly wishing things to die doesn't make it so...
      - tinus_hn 8y ago
        Great, so everyone’s happy!

lykr0n 8y ago

Just rip the band-aid off. Some of the async stuff in Python 3 is awesome. A bit curious that 3.4 has been dropped, as that's the stock Python 3 shipped for CentOS 7.

gammateam 8y ago
Debian also does not have anything above python 3.4 on the stable packages branch 3.6 has been dev and test since 2016
- lykr0n 8y ago
  It's not very clear, but this release is last release supporting 2.7 & 3.4. 1.5.6 supports 3.4.
  - Thorrez 8y ago
    I don't understand your comment. Version 1.5.6 of what? The NumPy 1.16.0 notes say > Support for Python 3.4 been dropped, the supported Python versions are 2.7 and 3.5-3.7. That definitely sounds like NumPy 1.16.0 doesn't support python 3.4.
- mehrdadn 8y ago
  Why in the world is Debian like this? Their buggy latexmk is also from 2015. Somehow I feel like every system that I want to keep updated stays on an old version, and every system that I want to keep pinned to some version just force-feeds me its updates...
  - geofft 8y ago
    Because it's the stable branch, and it gets no major version updates for anything after release, nor any new packages, just bugfixes to the current version. There is backports, and I've thought about maintaining a newer Python interpreter in backports (when I was working for a company using Jessie and trying to use a Debian stack for everything and sort of wanting async syntax). You could introduce python3.6 or python3.7 as a new package in backports. But it would be extremely hard to update the Python modules in Debian to the newer version, too, because there's just a "python3-foo" package for each module, so you'd either have to recompile all binary modules and patch them to work on the newer Python as necessary (and patch anything using async or await as regular identifiers....), or you'd have to introduce an interpreter that intentionally wasn't compatible with modules installed as Debian packages. (Or you could introduce an interpreter that tried its best and failed randomly, which seems worse than either option.) I'm personally sympathetic to wanting to get /usr/bin/python3.6 from my OS even if the only useful thing to do is put a virtualenv on top, but I think it makes sense to just install Python yourself into /usr/local at that point. Re latexmk, it looks like the volunteer maintainer hasn't updated it since 2015, and there's a culture of not stepping on people's toes and waiting a while before assuming they're inactive or no longer care. But it's been updated in the development release. The current changelog https://metadata.ftp-master.debian.org/changelogs/main/l/latexmk/latexmk_4.61-0.1_changelog https://metadata.ftp-master.debian.org/changelogs/main/l/lat... has a bunch of "NMU" entries, non-maintainer uploads.

anonymousCar 8y ago

When can we start calling Python 2.7 legacy code?

ggm 8y ago
Now. seriously. I think we have to treat it as legacy code now.
gnulinux 8y ago
EDIT: My comment is grossly misunderstood and I cannot delete my comment. I did not imply python 3 causes bad code, I was trying to tell a story about how "our" python 2 code is handsome and python 3 code is ugly; sorta implying python2 is not necessarily legacy code. I have absolutely no problem with python 3 and prefer it over python 2. I do not want to start a 2 vs 3 flamewar please just ignore this comment. === My company has >1 million line of python 2.7. About 1.5 year ago we managed to pass our test harness (about 80% line coverage) in python 3. At the moment we can't do that but we believe if we tried hard for a few weeks we can do it again too. I don't know how we define "legacy code" but I code in this codebase everyday and the code is actually very pretty and understandable. We also have a python 3 project (only a few thousand line of code) and god that code is definitely ugly as shit. Even after python2 goes unmaintained, I will still think our python3 code looks more like legacy.
- nas 8y ago
  If your Python 2 code is clean and your Python 3 is ugly, I don't know what the hell you are doing. They are almost the same language. Are you trolling?
  - S4M 8y ago
    Probably the Python 3 code was rushed and/or written by an inexperienced programmer. That would just be a coincidence, nothing to do with Python 2 or 3.
  - ovi256 8y ago
    The narcissism of small differences: it makes us notice differences (and dislike the differences) between things that are mostly identical to outside observers.

James_Owens_69 8y ago

Nope. Python 2.7 is and will continue to be used in scientific labs. Nobody will upgrade their working scripts.

sbrother 8y ago

The only thing keeping me on Python 2.7 is Apache Beam, but it's becoming increasingly painful and I'm close to just using a different technology rather than deal with making all my code py2 compatible in 2019...

rasmi 8y ago
For those interested, you can track Beam Python 3 support progress here: https://issues.apache.org/jira/browse/BEAM-1251 https://issues.apache.org/jira/browse/BEAM-1251

deleted 8y ago

[deleted]

MichaelMoser123 8y ago

Right now I don't think that python2.7 is very well supported in 1.16. Had to build a docker the other day that uses python2.7 and while building the docker it got numpy 1.16 from the pip mirror. Now import of numpy failed so that I had to revert to the previous version of numpy.