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

111–120 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#111

Post by Figs »

SatvikBeri wrote: post #65
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…

Optional type annotations did it for me - I don't usually use them, but I find them very helpful on a few types of tasks.

Could you please elaborate on this?

Re: Numpy: Plan for dropping Python 2.7 support

#112

Post by fro0116 »

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…

Just adding my random piece of anecdata:

docker-compose uses Python2 and has encoding issues on Windows that have no real workarounds other than upgrading to Python3: https://github.com/docker/compose/issues/2775

Re: Numpy: Plan for dropping Python 2.7 support

#113

Post by lemoncucumber »

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…

Not having a story for interoperability between 3 and 2 was incredibly shortsighted. The migration path from Objective-C to Swift is an example of how to do this sort of transition right; Python got it wrong.

Widespread adoption of Python 3 would've happened years earlier if you could start a new project in Python 3 and not have to worry about libraries you want to use not supporting it yet.

Re: Numpy: Plan for dropping Python 2.7 support

#114

Post by vetinari »

kajecounterhack wrote: post #97
brians wrote: post #48

Earlier quoted context omitted.

The change to string handling justifies it for me. Writing `u’foo’` everywhere is a pain, and the rest of the 2.7 model is extraordinarily prone to runtime errors. With 3.6, I don’t have those problems.

+1 Just because we learned to work around unicode issues doesn't mean they're not completely bonkers in 2.7

Most people didn't learn to work around unicode issues during the 2.7 time frame.

Many third party modules tended to explode spectacularly with encode/decode errors, when they were fed non-ascii strings, when used by people who write using all these funny characters.

Just the correct handling of strings in Python 3 alone is a hell of a reason to switch to it.

Re: Numpy: Plan for dropping Python 2.7 support

#115

Post by dbcurtis »

pc2g4d wrote: post #63
brians wrote: post #48

Earlier quoted context omitted.

The change to string handling justifies it for me. Writing `u’foo’` everywhere is a pain, and the rest of the 2.7 model is extraordinarily prone to runtime errors. With 3.6, I don’t have those problems.

Yeah, I was pretty much sold on Python 3 when I stopped having to use the `codecs` module to read my files and when it would strictly enforce the separation between `bytes` and `str`, rather than having to manually track what sort of sequence I was dealing with.

Yes, yes. My Python life is mostly about impelemnting odd protocols with Twisted. Will probably get serious about asyncio soon, but I have a lot of historical Twisted to deal with ATM.

I've noticed that the "Who cares about Python 3" types are not the people working on the kinds of problems I am. So my conclussion is that for many kinds of problems the benefits of Python 2 are kind of meh, so people stay in their comfort zone. For some kinds of problems, Python 3 is a huge, huge win over Python 2. Whether or not someone is a Python 3 advocate says more about the kinds of problems they work on than anything else.

Re: Numpy: Plan for dropping Python 2.7 support

#116

Post by eesmith »

makapuf wrote: post #101
eesmith wrote: post #85

Earlier quoted context omitted.

I agree that they were not very different languages. I did port code from Python 1.5.2 to Python 2. It required two minor changes, because "from X import *" was no longer allowed inside of a function. As a similar example, the transition from 2.5 to 2.6 meant that an assignment like "as = 0" (which might initialize a counter for the number of 'a's found) was no longer legal either.

Which makes me wonder how much of the incompatible changes that triggered the python 3000 change could have been introduced gradually. I mean 10 years could have been a long time to introduce small breaking changes one from future import at a time...

The future import technique works well for syntax changes which only affect a single module.

It doesn't help with objects passed between modules. For example, if s is a byte string, then "for c in s" returns a 1-byte string in Python 2 and integers in Python 3.

But if the string was created in a Py2 module and passed to a Py3 module, then what API should it present?

In principle there could be a wrapper to present the correct API. However, that's complicated, and not interesting compared to, say, a new methods for doing asynchronous programming.

This sort of backwards compatibility can be done. I've heard about IBM doing it for ... REXX, perhaps? .. where a program and perhaps even a module could declare which version to use. But it's expensive. And despite its popularity, there aren't scores of companies paying millions of dollars to ensure this level of compatibility,

Re: Numpy: Plan for dropping Python 2.7 support

#117

Post by skierscott »

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…

> 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 better async support

Re: Numpy: Plan for dropping Python 2.7 support

#118

Post by shrimpx »

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.

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

Re: Numpy: Plan for dropping Python 2.7 support

#119

Post by acqq »

nas wrote: post #59
derefr wrote: post #40

Earlier quoted context omitted.

You know the phrase, "you don't have to go home, but you can't stay here"? You don't have to move to Python 3, but Python 2 is gonna be EOLed. If you don't agree with Python 3's stances on things, it might be time to find another language entirely.

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 fuup 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 a year ago, I've installed "just" Python 3 on my main computer -- "Python 3 is mature enough" I've thought. Then I wanted to solve some problem X. Found the code that does 90% on the web. Try to run -- doesn't work on Python 3. Adjusting it. It runs after my changes, but I've lost time for something unnecessary. Then I've tried to solve some problem Y. The story repeats. The third time, I've just decided that it's not worth. I've installed 2 again and I can't be happier.

And all that was for my non-Numpy related work. There were some years where the libraries using Numpy were only Python 2, even after Numpy got its own 3 version.

So Python 3 was so very wrong for too long. The worst upgrade path I've lived through. And completely unnecessary. It was absolutely technically possible to make it much much easier to move.

Re: Numpy: Plan for dropping Python 2.7 support

#120

Post by yeukhon »

jwilk wrote: post #32
raker wrote: post #3

Good to see that it will be a quiet transition. Linus would approve.

Linus?

My guess is referring to Linus' philosophy on how software should be developed and maintained, especially in his own Kernel project. See http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html
Post reply on HN