Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NumPy 1.16 is the last release to support Python 2.7

github.com

Post reply on HN
Print view View original

81–90 of 115 posts

Re: NumPy 1.16 is the last release to support Python 2.7

#81

Post by raxxorrax »

mehrdadn wrote: post #65
raxxorrax wrote: post #62

Earlier quoted context omitted.

Debian was never cutting edge. If you want that, you would either have to switch your branches or change the distribution. There are quite a number of other distributions based on Debian with more recent software. But I wouldn't want Debian to change their release behavior. And to be honest regarding different versions: Python has always been a special needs kid in this regard.

I feel like there should be a more reasonable middle ground between 3+-year-old software and cutting-edge?

True, there probably is, but Debian is pretty known to be conservative towards newer releases.

Re: NumPy 1.16 is the last release to support Python 2.7

#82

Post by sametmax »

sweettea wrote: post #78
sametmax wrote: post #72

Earlier quoted context omitted.

12 years. It's all been very usable for 6 years. So you had 6 years to use the six or python-future lib, and 6 years to remove it. 100k lines, it's a 2 weeks job if your code is properly tested. It's quite ok given python is 25 years old and asked for it once. But good news, you don't have to do it. Python 2.7 will still work after 2020. We, the community, will just stop working on it for free. You can start paying u…

I'm a big fan of Tauthon, a backwards-compatible Python 2.7 fork with some features backported from Python 3. Personally I've yet to see a Python 3 feature that would be useful in my code.

After 15 years of python, going from client to client, my experience is the opposite: i've yet to see a code base that would not benefit from python 3. Usually people saying that just don't know much about python 3.

However, I understand that those benefits might not be motivation enough to migrate in some contexts.

In those cases, I advise to freeze the project in time, isolating it by vendoring dependancies and either compile it with nuitka or distribute it in docker.

Re: NumPy 1.16 is the last release to support Python 2.7

#83

Post by mehrdadn »

raxxorrax wrote: post #81
mehrdadn wrote: post #65

Earlier quoted context omitted.

I feel like there should be a more reasonable middle ground between 3+-year-old software and cutting-edge?

True, there probably is, but Debian is pretty known to be conservative towards newer releases.

Is there any distribution besides Arch that isn't like this? Alpine is also pretty bad about this, and I haven't tried other distros in years.

Re: NumPy 1.16 is the last release to support Python 2.7

#84

Post by raxxorrax »

mehrdadn wrote: post #83
raxxorrax wrote: post #81

Earlier quoted context omitted.

True, there probably is, but Debian is pretty known to be conservative towards newer releases.

Is there any distribution besides Arch that isn't like this? Alpine is also pretty bad about this, and I haven't tried other distros in years.

No idea. I use mainly Debian but I think Ubuntu has a more aggressive update policy and is based on Debian. Not sure about RH since I don't know a lot about their package managers. But CentOS and Fedora are probably also quite up to date.

Re: NumPy 1.16 is the last release to support Python 2.7

#85

Post by mehrdadn »

raxxorrax wrote: post #84
mehrdadn wrote: post #83

Earlier quoted context omitted.

Is there any distribution besides Arch that isn't like this? Alpine is also pretty bad about this, and I haven't tried other distros in years.

No idea. I use mainly Debian but I think Ubuntu has a more aggressive update policy and is based on Debian. Not sure about RH since I don't know a lot about their package managers. But CentOS and Fedora are probably also quite up to date.

Oh Ubuntu is like Debian to me... in fact when I was taking about Debian this whole time I was actually talking about Ubuntu. Its latexmk is the one that's old.

Re: NumPy 1.16 is the last release to support Python 2.7

#86

Post by Macha »

detaro wrote: post #75
ThatPlayer wrote: post #73

Earlier quoted context omitted.

Arch Linux has the packages the other way around: the 'python' package is Python 3 while there is a python2 package and binary. I guess Ubuntu has it that way to stop the breaking changes however

You should expect python to be Python 2 because that's the official recommendation, for compatibility: https://www.python.org/dev/peps/pep-0394/ New code has no problem explicitly requesting python3, old code needs changing to request Python 2, but if you touch it anyways it's of course safer to make that change.

In case anyone thinks Arch is being crazy here and ignored the PEP (and doesn't read the PEP), note the change here was written in 2011 and approved in 2012 based on Arch's experience moving to python 3 by default in 2010.

Re: NumPy 1.16 is the last release to support Python 2.7

#87

Post by orf »

CJefferson wrote: post #74
ric2b wrote: post #71

Earlier quoted context omitted.

> I found code all over the place which broke for unicode reasons (we were reading in the output of GCC, and printing it back out, and it didn't work any more as GCC doesn't output valid UTF8 in some cases). That means the code was working with raw bytes, not utf-8 strings, so that's what you should convert to on Python3. That means using `.encode()` and `.decode()` or using bytestrings. Python3 doesn't break string…

The problem I had with python is that (because it is dynamically typed), and quite a few methods take both bytes and strings, it can be tricky to track what you have and often things don't break until you feed in a non-UTF8 string. I found it much easier in Rust, as the two types are just distinct, and an incorrect program just fails to compile.

In Python 3 they are two distinct types as well.

Re: NumPy 1.16 is the last release to support Python 2.7

#88

Post by wenc »

walrus1066 wrote: post #57
brylie wrote: post #54

Earlier quoted context omitted.

What percentage of those lines do you estimate will need changes?

Imagine that's part of the challenge. Since python is dynamically typed/duck typed, it's hard to audit all usages of a variable. I.e. If I see a py2 string declared, how can I be 100% sure I don't break downstream components by making it a bytes or py3 unicode string? Some might be using it as the former, others the latter. You'd need insane test coverage, of all possible code paths, to be 100% confident.

I was responsible for the Python 2 to 3 migration for various code bases at work. I used 2to3 to check for issues, but did most of the code rewrites by hand.

Most of the conversion difficulties were related to Unicode/text/binary string handling in Python 3, and 2to3 didn't catch all of them. This was the biggest challenge of the entire process. Stuff would fail in production because due to improper string handling. Python 2 was remarkably permissive (i.e. loosy goosey), whereas Python 3 is stricter and arguably more correct, but this strictness has a cost.

The other class of problems is the restructure of certain std libs, like urllib. We took the opportunity to move away from "urllib" to "requests".

This site [1] was invaluable in understanding the migration issues.

All in all, apart from breaking Unicode issues, the migration process was fairly easy.

[1] http://python3porting.com/problems.html

Re: NumPy 1.16 is the last release to support Python 2.7

#89

Post by coldtea »

tinus_hn wrote: post #60
coldtea wrote: post #52

Earlier quoted context omitted.

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

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

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

Re: NumPy 1.16 is the last release to support Python 2.7

#90

Post by jhasse »

geofft wrote: post #11
mehrdadn wrote: post #7

Earlier quoted context omitted.

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

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 pytho…

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

No, Debian stable doesn't get bugfixes, only if those bugfixes are for security issues! (or some really severe bugs)

Example: Debian's Python is still 3.4.2, not 3.4.9!

Post reply on HN