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

71–80 of 115 posts

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

#71

Post by ric2b »

CJefferson wrote: post #66
brylie wrote: post #54

Earlier quoted context omitted.

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

The problem is which lines. 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). In the end I decided moving to Rust was less work than Python 3 (in terms of being sure my program was reliable and wouldn't error out with unicode errors).

> 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 usage, it makes you do it correctly. Expect a lot more of that kind of pain by moving to Rust (not saying it's not worth, you'll indeed get more correct programs done).

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

#72

Post by sametmax »

coldtea wrote: post #67
pjmlp wrote: post #53

Earlier quoted context omitted.

I guess 10 years was more than enough time, maybe 2.x series will be the Cobol of Python world.

10 years where the first P3K versions were unusable and the rest still didn't have tons of dependencies? Yeah, right. There's a reason even companies with tons of resources like Google still use 2.7.

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 us, or do the job for free like we did since 1991.

You can also migrate to another tech, but they will break things as well, and they won't give you 12 years to move. Ruby and node gave 2 years. Node forked 2 times. And it's a google based tech.

I'm tired of hearing complains, given how good you have it.

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

#73

Post by ThatPlayer »

acqq wrote: post #70
j1elo wrote: post #63

Earlier quoted context omitted.

Let's check the package "python" in Ubuntu... 14.04 (2014): Python 2 16.04 (2016): Python 2 18.04 (this is obvious but... less than 12 months ago!): you guessed it, Python 2 (!!!) So, still in 2018 and until 2020 (when I guess the next LTS release of Ubuntu is scheduled) all instructions over the internet telling you to run "python" or "pip install" will run Python 2 if copied into your Ubuntu terminal. I already sai…

You should assume that python means “2” and python3 what it says in the name. The bigger problem is that invoking “python3” and having a script developed for “python3” still doesn’t guarantee that the script will work, there were incompatible changes during python3 history.

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

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

#74

Post by CJefferson »

ric2b wrote: post #71
CJefferson wrote: post #66

Earlier quoted context omitted.

The problem is which lines. 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). In the end I decided moving to Rust was less work than Python 3 (in terms of being sure my program was reliable and wouldn't error out with unicode errors).

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

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

#75

Post by detaro »

ThatPlayer wrote: post #73
acqq wrote: post #70

Earlier quoted context omitted.

You should assume that python means “2” and python3 what it says in the name. The bigger problem is that invoking “python3” and having a script developed for “python3” still doesn’t guarantee that the script will work, there were incompatible changes during python3 history.

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.

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

#76

Post by mrweasel »

coldtea wrote: post #67
pjmlp wrote: post #53

Earlier quoted context omitted.

I guess 10 years was more than enough time, maybe 2.x series will be the Cobol of Python world.

10 years where the first P3K versions were unusable and the rest still didn't have tons of dependencies? Yeah, right. There's a reason even companies with tons of resources like Google still use 2.7.

The issue was that some people didn't even start writing Python 3 compatible code.

I would go so far as to say that Python 3.4 was the first one you could really use in production, that leaves you with 5 years to handle the upgrade. Still before that you should at least have started to add basic stuff like importing print_function and at testing all new stuff against Python 3. Many just kept ignoring Python 3 and wrote line after line of new incompatible Python 2 code.

I no longer feel sorry of those who are stuck on Python 2.7 and now have less than a year to upgrade. At this point it's your own fault.

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

#77

Post by uryga »

drej wrote: post #58
backprojection wrote: post #12

Earlier quoted context omitted.

Same here. Dataclasses and type annotations are fantastic, not to mention f-strings.

This is all fine for personal/proprietary purposes, but open source can't be that cutting edge. While type annotations are probably fine (3.5), f-strings (3.6) or dataclasses (3.7) won't make it to mainstream OSS anytime soon. But they are great features nonetheless.

> open source can't be that cutting edge.

what?

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

#78

Post by sweettea »

sametmax wrote: post #72
coldtea wrote: post #67

Earlier quoted context omitted.

10 years where the first P3K versions were unusable and the rest still didn't have tons of dependencies? Yeah, right. There's a reason even companies with tons of resources like Google still use 2.7.

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.

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

#79

Post by josteink »

simonh wrote: post #61
mrosett wrote: post #8

Earlier quoted context omitted.

The code I've written recently relies heavily on async and data classes, both of which are recent additions. I can't imagine choosing Python 2 at this point.

My team is moving across from Bash to Python for non-trivial scripting. I hate it, but we're adopting Python 2.x. Our old servers are on SLES 11 which has Python 2.6 and even our new boxes have RHEL 7 which has Python 2.7 only by default. Getting the base system packages updated across all our systems and environments would be monumentally painful, so we're really stuck. It's not that Python 2.x is painful to use or…

> Our old servers are on SLES 11 which has Python 2.6 and even our new boxes have RHEL 7 which has Python 2.7 only by default.

Not to sound condescending... But why does this single default matter that much?

I'm sure you install lot of things onto these machines which isn't there by default, right?

Why is installing Python 3 on top of all those other non-default packages such a problem?

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

#80

Post by jklepatch »

kalefranz wrote: post #19
lykr0n wrote: post #4

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.

I generally try to leave the system python alone. Use pyenv or conda to get the python interpreters for your own code and apps.

How does this compare with managing python with brew?
Post reply on HN