Live data from Hacker News

Numpy: Plan for dropping Python 2.7 support

github.com

311–320 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#311
post #137

Earlier quoted context omitted.

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

> Only Python 3? Are we there? In my experience, for my purposes and use cases, obviously not, exactly as I wrote above. And it didn't have to be that way for most of the code, I claim that, knowing how little additional code were needed to have a different result: compare with the Linux Kernel, much more complex piece of code, where "kernel never breaks user code" because Linus set that goal. Python is much, much le…

I don't know the details (because I don't understand unicode) but I am not sure what you said is possible.

But to me ASCII seems like a hindrance.

``` fmt.Println("Hello, 世界") ```

This line of go lang looks beautiful. I bet they never have to worry about bytes vs Unicode.

Here is python...

https://www.youtube.com/watch?v=sgHbC6udIqc

I'll add one more assertion to the list. People are born and people die. It is not fair for us to impose our mistakes and sins to the next generation. With that being said, my thought was simply all the scripts that are in python (even the simple build for Firefox was python 2 only last time I checked).

The way forward for anyone new to python is for us to tell them: Python 2 doesn't matter. Don't look at it. Learn python by which I mean 3.0+

I still don't get why Google of all places can't support python 3 in its standard app engine. To me it sounds like standard is deprecated for the flexible (which doesn't have a free tier).

Re: Numpy: Plan for dropping Python 2.7 support

#312
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…

RHEL7 "runs on" Python 2 and is to be supported at least until 2024, so I don't think Python 2 is going away.

Re: Numpy: Plan for dropping Python 2.7 support

#313
post #100
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…

There should have been more innovation, making Python 3 compelling enough for Numpy use to deprecate Python 2 in 2010 for obvious, noncontroversial technical reasons. Instead there has been a thoroughly unpleasant and glacially slow transition between "we have to support Python 3 for bleeding edge users" to "we have to support Python 2 for retro users".

Re: Numpy: Plan for dropping Python 2.7 support

#314
post #43
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…

> it runs faster than Python3

Generally speaking, Python 3 is actually faster now. I am a bit surprised that no one else has commented on this. There was a talk about performance recently (https://www.youtube.com/watch?v=d65dCD3VH9Q). To sum it up, some parts are slower and other parts are faster, and the reasons depend on two questions:

1: Is it using a lot of small ints? Python 3 changed int from being small int to long int, and for work which deals with massive amount of ints this will result in a slow down. If for some reason you want to use a pure Python implementation of AES rather than using hardware acceleration (generally builtin to the CPU) or a C implementation, or the one built in the linux kernel, then you will hit the performance test that get the biggest negative difference between python 2.7 and master. Then there is numpy which uses C modules that can happy do things as small ints.

2: Bytes -> Unicode. Libraries that are Unicode unaware will run faster than libraries that are Unicode aware. The feature to understand that "ö" is a Swedish letter and not several characters does cost some CPU time. For parsing where per character manipulation is relevant (like say HTML), such parsing will be a bit slower in python 3.

Practically everything else is faster now in python 3.

Re: Numpy: Plan for dropping Python 2.7 support

#315
post #43
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…

Surprised nobody posted this yet: https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-...

It's a presentation by core developer Brett Cannon which explains what's better about Python 3. The list is quite long for an HN comment, so I'm not going to repeat it here.

Now it's pretty dated as there had been more things added like async, so Python 3 is even better now.

Re: Numpy: Plan for dropping Python 2.7 support

#316
post #307
post #292

Earlier quoted context omitted.

Yep, I'm always surprised by the number of people of people here who dismiss the usefulness of unicode. Not "dismissing" the hard way, but simply saying it's not a problem. I understand that we may have a lot of western/english people here but, unicode for me is a life saver. For example, I work on stuff for french speaking people, and I need the euro sign. In that very simple case, unicode already solve many issues…

You do realize unicode has been "built into Python" pretty much since the beginning (Python 2.0, 17 years ago), right? The main difference is that unicode has a more efficient internal storage since Python 3.3+ (a neat technical detail), and that mixing bytestrings and unicode will fail with an explicit error since 3.0+ (a good idea IMO). But that Python 2.7 didn't support unicode is simply FUD.

I don't think anyone claimed it didn't support Unicode. Only that it allowed mixing bytes / strings and the default type most people used from the beginning was str. That's a trap that they'll regret the moment they actually need to handle something outside of Latin-1.

Lots of python 2 code out there fails because the default option was simple but bad. I know, because my name broke the CI pipelines in a few different projects.

Re: Numpy: Plan for dropping Python 2.7 support

#317
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…

https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-p... is a fairly good summary. There are loads and loads of syntax improvements (I personally love the new unpacking), new features, and other enhancements. Sure, you can continue using Python 2, and it's going to work for you. I guess you can also keep using Windows XP (no reason not to use it beyond the fact that Microsoft has gotten bored of providing secu…

> and code using your PS/2 keyboard...

That's not even a hipster thing, it's quite mainstream with gaming keyboards...

Re: Numpy: Plan for dropping Python 2.7 support

#318
post #307

Earlier quoted context omitted.

You do realize unicode has been "built into Python" pretty much since the beginning (Python 2.0, 17 years ago), right? The main difference is that unicode has a more efficient internal storage since Python 3.3+ (a neat technical detail), and that mixing bytestrings and unicode will fail with an explicit error since 3.0+ (a good idea IMO). But that Python 2.7 didn't support unicode is simply FUD.

I don't think anyone claimed it didn't support Unicode. Only that it allowed mixing bytes / strings and the default type most people used from the beginning was str. That's a trap that they'll regret the moment they actually need to handle something outside of Latin-1. Lots of python 2 code out there fails because the default option was simple but bad. I know, because my name broke the CI pipelines in a few different…

Did you actually read the thread you're replying to, or are you on auto-pilot?

Re: Numpy: Plan for dropping Python 2.7 support

#319
post #131

Earlier quoted context omitted.

That is like the biggest fake argument ever. There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing. The are plenty of people ready to step up to continue Py2 support (Even I would be glad to help). This is a pure political decision based on ideology.

As the codebase grows, you need to maintain 2 growing codebases, how is that not increasing the burden? Official support will be dropped by 2020, by then you will be relying on the community (who ?) to provide bug and security fixes. I'm not aware of anybody stepping up and declaring they will take over maintenance. At this point, insisting on python 2 is the ideological "side". There's no practical nor realisitic re…

Can you be more precise with what you mean by "the community". It wasn't the community that said it was dropping support.

I've plan to migrate away from py2 by 2020 too, just not to py3.

Re: Numpy: Plan for dropping Python 2.7 support

#320
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…

The project failed because print was not a function, is not something one hears often.
Post reply on HN