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

121–130 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#121

Post by thanksgiving »

acqq wrote: post #119
nas wrote: post #59

Earlier quoted context omitted.

I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. A lot of that code is just never going to get ported to Python 3. Companies don't have the budget to do it. So, somehow there will still be a Python 2 interpreter to run the code, even after 2020. That said, when nearly all of the Python 3rd-party library developers are targeting Python 3, do you really wan…

> I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. Exactly. And that is the major fu up that Python 3 brought. There was no fundamental reason to make most of the Python 2 code incompatible with the "better" and "newer" version. The really good Python 3 would have accepted most of the Python 2 code and execute it, while allowing the new 3 "goodies." Only…

Only Python 3? Are we there? I thought we are not there yet? I thought there is a big push going on for fedora to go Python 3 only and it will likely not end before end of next year? I imagine Debian and Red Hat and Canonical will continue python 2 default for a while?

I'd be happy if I'm wrong though...

Re: Numpy: Plan for dropping Python 2.7 support

#122

Post by nonbel »

I am a python outsider, but like many others dealt with a lot of pain due to the simultaneous 2 and 3 versions.

Looking at the history, I see python1 ended at 1.6, and python2 ended at 2.7. Based on this the current python 3.6 seems to be nearing end of life. https://en.wikipedia.org/wiki/History_of_Python

So what will happen when python 4 comes out?

Re: Numpy: Plan for dropping Python 2.7 support

#123

Post by brownbat »

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…

This is an ancient argument because no one can convince you that you need 3 for your use case. All I can do is say why I like it, and list reasons that probably don't apply to you or you would have switched already.

For example, print and division made more sense to me in 3, judging from friends who taught 2 and said those were always sticky for some students in every class. Intuitive lowers the barrier to entry. (But 2 is probably more intuitive to you because it's second nature to you by now.)

Unicode--when I would test some tiny scripts with Chinese characters or weird ciphers--was pretty easy out of the box in 3.

On systems that only support 2 I find myself slipping in basically a 'from future import all the things.'

These are admittedly mostly cosmetics. But cosmetics matter for noobs like I was, or maybe still am.

I guess 3 also fixed ambiguity in corner cases for error handling? Never came up for me so I don't know much about that one.

You probably just don't have those use cases?

Two people could use distinct subsets of python and neither is using it wrong. Meaning... there could be reasons many of us want 3 that simply don't apply to you. Which sucks, because you get hit with switching costs to help the rest of us.

I think that's the recipe for an endless debate with two reasonable sides.

I will say py2 was already fragmented without 3. PaiMei only ran on... 2.4 maybe? You'd find weird projects that you liked that would then get abandoned. Suddenly you're shimming them all or running four versions. I think 3 woke people up to this as a problem--by making it much harder to patch and way more universal. That made the project more conscious about future and backwards compatibility. Those dividends will only be seen over time. I hope they vest but can't prove how or if they have.

I hope this is helpful... Just know that I'm not saying you're wrong to want to use something that works for you. Switching costs are a real thing, I know it sucks to feel dragged along. But py3 is a lot better for me and others, possibly because we're using the language for different things.

Re: Numpy: Plan for dropping Python 2.7 support

#124

Post by cname »

shrimpx wrote: post #118
matt_wulfeck wrote: post #88

Earlier quoted context omitted.

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.

Getting rid of the GIL is a big change. In py2.7 CPU-heavy threads are useless -- they lock up the process and starve other threads. py2.7 threads are only good for I/O heavy work. You can use multiprocessing in py2.7 but with a lot of caveats if you want to share state and file descriptors. IMO the GIL removal is the one thing "that's not easily available via back ports in 2.7".

GIL removal? Are you sure about that?

Re: Numpy: Plan for dropping Python 2.7 support

#125

Post by user5994461 »

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.

The price to switch is too high. A codebase that took years to write will take years to migrate. To make the matter worse, it's impossible to support both python 2 and python 3 at the same time.

Re: Numpy: Plan for dropping Python 2.7 support

#126

Post by user5994461 »

jhasse wrote: post #84
CJefferson wrote: post #14

Earlier quoted context omitted.

What? No! Python 2 is only 17 years old. I can still run Java, C, C++ and Perl 5 (picking the first 4 languages that occur) that were written before then, with no problems.

Most C++ code wont compile for multiple reasons. For example using namespace std will result in errors if your code calls a function which is now part of std.

I actually think that migrating from Qt4 to Qt5 has a lot of similarity with python 2 to python 3. Not sure why there aren't more people doing the comparison.

Re: Numpy: Plan for dropping Python 2.7 support

#127

Post by ant6n »

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.

But you also got the "print-tax"!

Re: Numpy: Plan for dropping Python 2.7 support

#128

Post by brownbat »

takluyver wrote: post #74
Figs wrote: post #43

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

For anything non-trivial, 95% of the value is in the library ecosystem. So long as most prominent libraries kept releasing new features for Python 2 and 3, there's inevitably not a big pull factor to upgrade. That's changing as a number of major libraries start to make releases that require Python 3. From a library maintainer POV, I do want to use Python 3. There's no one killer feature, but rather a bunch of small o…

> For anything non-trivial, 95% of the value is in the library ecosystem.

Toy programs and rapid scripting and prototyping...

FWIW I love my trivial use of python.

Re: Numpy: Plan for dropping Python 2.7 support

#129

Post by gigatexal »

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.

Back posting anything to 2.7 was a mistake. It shouldn’t have happened because it offered a crutch to stand on instead of spurring ports to 3. 3.x has been around for years now. There was no excuse to have started porting an application that would have taken 3 or four years to do, 3 or four years ago. What did everyone think that 3.x python was a fad and not going anywhere?

Re: Numpy: Plan for dropping Python 2.7 support

#130

Post by amorphid »

brownbat wrote: post #123
Figs wrote: post #43

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

This is an ancient argument because no one can convince you that you need 3 for your use case. All I can do is say why I like it, and list reasons that probably don't apply to you or you would have switched already. For example, print and division made more sense to me in 3, judging from friends who taught 2 and said those were always sticky for some students in every class. Intuitive lowers the barrier to entry. (Bu…

It's pretty hard to make a case for transitioning from something that works pretty well to a new thing in general. The nicer the old thing is, and the wider it's been adopted, the harder the sell. That's just the way it is.

Too look at it a different way... If I see the benefit of & would like to make a change, actually making the change competes with all of my priorities. I'm under the impression that Python is used by many people who use reliable things with APIs that don't change often (I mainly of thinking of Bash & some Posix OS). I can see why they wouldn't be fans of making changes.

Personally I like using newer things, all other things being equal. That's mostly because it's easier to chat about recent stuff with people learning the same lessons I'm learning. Almost every time I ask a C/Bash/*NIX question on a Stack Exchange site, the question gets marked as a duplicate, links to a question with answers I had already, but failed to understand. That happens much less when inquiring on newer topics.

Post reply on HN