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

91–100 of 115 posts

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

#91

Post by coldtea »

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…

>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 took Flask several years, complaints, and a custom change for their use case, to port over.

Some people have actual production code which they don't rewrite for the fun of it (and even less with comically underestimated "2 weeks per 100K" runs), because the core decided a non-backwards compatible version is the future.

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

Well, you're not the "community", at best you're one committer. The community (not necessarily the core devs) will fork and maintain way beyond 2020, and it will be for free too.

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

Sorry, didn't know people must walk on tiptoes lest they tire you with their complains...

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

#92

Post by sametmax »

coldtea wrote: post #91
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…

> 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 took Flask several years, complaints, and a custom change for their use case, to port over. Some people have actual production code which they don't rewrite for the fun of it (and even less with comically underestimated "…

Says the person who has benefited from it for free for 25 years and doesn't have to pay the price for maintening it even further.

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

#93

Post by slondr »

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.

#!/usr/bin/env python3

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

#94

Post by mroche »

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.

I mean, RHEL 8 is shipping with Python 3.6 and Python 2.7 available. There is no standard /usr/bin/python without making the symlink manually, and the system uses its own internal python for dependent tooling, so it doesn’t conflict with user installed versions.

And, based on my experience, general open source is usually much more cutting edge than the larger distros, that’s the whole point.

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

#95

Post by LeanderK »

coldtea wrote: post #91
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…

> 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 took Flask several years, complaints, and a custom change for their use case, to port over. Some people have actual production code which they don't rewrite for the fun of it (and even less with comically underestimated "…

Well, programming languages evolve and to maintain a clean language (which python aspires to be), it has to cut some ties.

I think the overly backward-compatible way in which the change was managed really prolonged the adtoption and getting python 3.x to mature. The Python-Community was hanging between those versions far too long and it really hurt the ecosystem and the whole python-experience.

> Some people have actual production code which they don't rewrite for the fun of it (and even less with comically underestimated "2 weeks per 100K" runs), because the core decided a non-backwards compatible version is the future.

Of course, but you (probably) still have to maintain the code. And it's not a full rewrite, more an adaption. I find most changes to be quite mechanical. Also, it's not the python-comunities fault, you chose python and you're getting probably using it for some business purpose. So i think the python community can expect you to maintain it, including language adaptions. You can still ignore this and don't update, but libraries will probably start getting incompatible and there will come a time when things break. Wheter that's important enought to migrat is up to you.

I don't think it's fair to just complain loudly, after all, the python community is not expection a full rewrite. They have given enough time to migrate, i think took much, but it's still a lot. Being completely backward compatible forever was never promised, and i think is an complete anti-feature. Write once and never think about it is not the python-way, but having a clean, smart, elegant language. It also really hurts java, which just walks with all the backage of the past and glacial speed for language-updates, which probably is required when everything you do is going to be kept forever in the language.

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

#96

Post by VWWHFSfQ »

josteink wrote: post #79
simonh wrote: post #61

Earlier quoted context omitted.

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?

I prefer to install as few 3rd party packages as possible. In RHEL7 until recently Python 3 was only available via 3rd party repos, until EPEL added it. So now it's not that big of a deal to install python3, but before that why would I go about adding ius or something to get a modern python when there's a perfectly fine Python 2.7 built into the system for running sysadmin jobs?

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

#97

Post by VWWHFSfQ »

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.

there were incompatible changes during python2 history as well. RHEL shipped Python 2.4 forever, and now ships 2.7. There are many breaking changes between those two versions.

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

#98

Post by VWWHFSfQ »

mkesper wrote: post #64
simonh wrote: post #61

Earlier quoted context omitted.

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…

Please enable additional repos (EPEL, IUS) providing sane Python versions. Python 2.6 isn't even supported by pip anymore. RHEL appeals to "enterprise" people for claiming to be able to run the same software for ten years without adaptations. It's a seductive trap imho.

why would I add 3rd party repos to install a modern python when I can just run my sysadmin python scripts under the system python without worrying about it? python2 is a perfectly good python for 99% of the things need to do

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

#99

Post by lmm »

orf wrote: post #87
CJefferson wrote: post #74

Earlier quoted context omitted.

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.

They're not really "types" when you only find out at runtime.

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

#100

Post by emddudley »

throwaway2048 wrote: post #32
emddudley wrote: post #15

Earlier quoted context omitted.

> the stock Python 3 shipped for CentOS 7. What package are you referring to? As I understand it there is no "stock" Python 3 in CentOS 7. There is just what you can get from secondary repos, like EPEL, SCL, and IUS. Those repos now have 3.6 available.

However system level stuff will install 3.4 by default.

On a fresh virtual machine built from the 7.6.1810 minimal ISO the system Python is 2.7.5:

    [root@localhost ~]# python --version
    Python 2.7.5
RHEL 8 is where they are making Python 3 available as the system Python.

https://developers.redhat.com/blog/2018/11/14/python-in-rhel...

Post reply on HN