
NumPy 1.16 is the last release to support Python 2.7 - htfy96
https://github.com/numpy/numpy/blob/master/doc/release/1.16.0-notes.rst
======
lykr0n
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
Debian also does not have anything above python 3.4 on the stable packages
branch

3.6 has been dev and test since 2016

~~~
mehrdadn
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
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/lat...](https://metadata.ftp-
master.debian.org/changelogs/main/l/latexmk/latexmk_4.61-0.1_changelog) has a
bunch of "NMU" entries, non-maintainer uploads.

~~~
mehrdadn
Thanks for the explanation.

Re latexmk: so am I getting the development release on Arch? I get the 2018
version with texlive-core.

~~~
geofft
Sorry, I mean that the volunteer maintainer of the latexmk package in Debian
hasn't updated it since 2015. Arch probably has a newer version from the
latexmk authors (and I think Arch does not have the same culture of individual
package maintainers, in general).

~~~
mehrdadn
..Oh. Wow. Do distros not care if their packages are updated for 3+ years? I'd
have expected half their entire job is to make sure package maintainers are
actually maintaining packages...

~~~
int_19h
Eventually such packages get removed (usually when they stop building for
whatever reason). But if the package still works, having an old version of it
is still better than not having anything.

------
anonymousCar
When can we start calling Python 2.7 legacy code?

~~~
gnulinux
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
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
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.

------
sbrother
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
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)

------
MichaelMoser123
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.

------
oriol11
"Numpy 1.16 is good enough" \- Me in 2029

~~~
tinus_hn
Clinging on to the past for dear life..

~~~
coldtea
Or, if it ain't broken, don't fix it.

~~~
tinus_hn
Well, it’s open-source so you’re free to volunteer your resources and maintain
it yourself

~~~
coldtea
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
Great, so everyone’s happy!

