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

Numpy: Plan for dropping Python 2.7 support

github.com

Post reply on HN
Print view View original

181–190 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#181

Post by takeda »

Figs wrote: post #43
fredley wrote: post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth. I know Py…

You should give Python 3.6 a try and you will see.

There are many minor improvements and new functionality that working with it is so much enjoyable and make code more readable and shorter.

I got to a point where it feels like a chore whenever I have to use Python 2.7.

Re: Numpy: Plan for dropping Python 2.7 support

#182

Post by JoBrad »

skierscott wrote: post #117
Figs wrote: post #100

Earlier quoted context omitted.

> Isn't that a bigger problem for Python 2.7 hold outs? Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think…

> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had be…

pathlib is pretty awesome, too. Has some growing pains, to be sure, but overall it makes paths so much easier than without it.

Re: Numpy: Plan for dropping Python 2.7 support

#183

Post by pfranz »

skierscott wrote: post #117
Figs wrote: post #100

Earlier quoted context omitted.

> Isn't that a bigger problem for Python 2.7 hold outs? Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think…

> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had be…

I haven't jumped into Python3 yet (for work/legacy reasons), but I'm really looking forward to nested exceptions and pathlib. Also, even when just working in English, unicode (or special classes for strings) were really annoying when interfacing with other libraries like Qt or databases.

Re: Numpy: Plan for dropping Python 2.7 support

#184

Post by traverseda »

Figs wrote: post #43
fredley wrote: post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth. I know Py…

f strings.

https://docs.python.org/3/whatsnew/3.6.html#pep-498-formatte...

Re: Numpy: Plan for dropping Python 2.7 support

#185

Post by Ivoah »

Pxtl wrote: post #76

After such a long and painful road from 2 to 3, I feel like the Python developers aimed too low in fixing the legacy problems that existed in 2. All that time for Unicode. Not concurrency or type safety or static guarantees or better lambda syntax or anything fun like that. Just Unicode.

> better lambda syntax

What do you mean by better lambda syntax? Is there something that you feel isn't adequate in the current syntax?

Re: Numpy: Plan for dropping Python 2.7 support

#186

Post by takeda »

Figs wrote: post #100
nas wrote: post #75

Earlier quoted context omitted.

> Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. It seems pretty clear now that 3rd party library developers are going to stop releasing packages that support 2.x and target only 3.x. Isn't that a bigger problem for Python 2.7 hold outs? Originally, I was not super…

> Isn't that a bigger problem for Python 2.7 hold outs? Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think…

> Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3.

Actually if you ever wrote code that you wanted to make backwards compatible with Python 2.7 is a nightmare. The fact that they did not even wait until 2020 before depreciating it is a testament to that.

> I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think this is a good thing now -- i.e. what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago?

I don't know about others, I always been supporting Python 3 since 3.4. I feel like many people were complaining about Python 3, but never used it, then eventually started using and realized that it is not so bad.

> I may do that.

You should, is much more enjoyable experience. Perhaps because you're so used to Python 2, you don't notice, but Python 2 has a lot of warts that accumulated over the years.

Re: Numpy: Plan for dropping Python 2.7 support

#187

Post by x14 »

skierscott wrote: post #117
Figs wrote: post #100

Earlier quoted context omitted.

> Isn't that a bigger problem for Python 2.7 hold outs? Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think…

> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had be…

Don't forget how nice super().__init__() is.

Re: Numpy: Plan for dropping Python 2.7 support

#188

Post by pfranz »

rossdavidh wrote: post #6

At the SciPy 2017 conference, for the first time I saw speakers who were presenting new libraries say that they were not going to be developing Python2 versions. Quite a change from a year or two ago.

Similarly, I'd always watch at least a handful of Pycon talks every year. Last year I couldn't really find anything relevant to Python2. The closest thing was and update on removing the GIL...but that was more informational than practical for me.

(I'm still stuck using Python2--not by choice)

Re: Numpy: Plan for dropping Python 2.7 support

#189

Post by crusso »

kbd wrote: post #165
cpncrunch wrote: post #157

Earlier quoted context omitted.

>For the good of any computer language, old versions need to eventually die off. I would say instead: for any good computer language, new versions need to retain compatibility with old versions. Every single system I run has python 2.7 (including my brand new Macbook running latest OS X). Luckily I don't need numpy, and I can probably do without python at all if I have to. Compare to perl: I can run old perl scripts…

Perl is a weird language language for you to cite when we're talking about languages that do major transitions well. Perl 6 was created because Perl 5 was an evolutionary dead end, took 15 years, has no adoption, and Perl 5 usage shrunk tremendously in the meantime. Not saying this glibly as I love Perl and I hope Perl 6 sees some adoption, but come on now. Also remember that Perl 5 itself was nearly a complete rewri…

Exactly my thought regarding the need to evolve as a language. Perl is mostly dead because it didn't keep up with the times and I say that as a person who spent a tremendous amount of time learning and using Perl. The Schwartzarian transform was a beautiful thing to behold.

Re: Numpy: Plan for dropping Python 2.7 support

#190

Post by pfranz »

matt_wulfeck wrote: post #88
gigatexal wrote: post #86

Legacy python needs to be thought of as the plague and avoided. There’s so much awesome in the 3.5+ land of python. This is a good thing.

There’s really not anything major in 3 that’s not easily available via back ports in 2.7. Or else why do you think people aren’t bothering to pay the price to switch? This is also the reason maintainers are bringing out sticks. They realize the carrots just aren’t that tasty.

> maintainers are bringing out sticks

Library maintainers? Why do they care what Python you use? They're dropping 2.x support because it's a burden to them.

I'm still using Python2, but the things I know I'd use that aren't back ported are; well, having to download something to backport functionality (batteries included is a selling point for Python), native namespace packages, nested exceptions, function annotation, and not having to treat unicode differently when dealing with external libraries like Qt or databases. I often backport lru cache, pathlib, and terminal size came up for me last week. The other new things look interesting, but since I'm not using Python3 I can't really evaluate them.

Post reply on HN