Live data from Hacker News

Numpy: Plan for dropping Python 2.7 support

github.com

61–70 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#61
post #9

It would be interesting to see whether Python 2 is the longest supported major version for a programming language.

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.

Which version? Aren't we on Java 9 now?

Re: Numpy: Plan for dropping Python 2.7 support

#62
post #16

Earlier quoted context omitted.

Yeah, for the longest time everyone kept using library support as an excuse for sticking with 2. But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule. The only one that comes to mind for me is fabric, to be honest.

I have always been interested in that cycle. We use 2 because NumPy supports it still. NumPy supports it because we use it. If a major library had dropped support earlier on, I am curious what would have happened.

I bet the same dynamic happened with Linux distributions including Python 2 as the default as well. Double whammy.

Re: Numpy: Plan for dropping Python 2.7 support

#63
post #48
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…

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.

Re: Numpy: Plan for dropping Python 2.7 support

#64
post #48
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…

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.

Yes, and while performance on some tasks has gotten worse, on others it has got much better - JSON serialisation in particular, which was huge for us. Python 3.7 will be faster again in many areas.

Re: Numpy: Plan for dropping Python 2.7 support

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

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.

Re: Numpy: Plan for dropping Python 2.7 support

#66

I've said it before, I'll say it again. I don't care for everything-is-unicode-by-default. You can take my Python 2 when you pry it from my cold dead hands.

I'm open to the argument that Python 3's handling of string encoding is not ideal. But after using Python 3, I'm not willing to go back to a language that allows the programmer to freely mix encoded and decoded strings and uses the same type to represent both. That way lies insanity, and I'm glad to be rid of it.

In Python 2, I could never seem to figure out how to do string encoding properly. After trying to reason about the code and put the calls to str.encode() and str.decode() in what I thought was the right place and inevitably failing, my only recourse was to sprinkle random calls to str.encode() and str.decode() throughout my code like magic pixie dust until errors stopped happening. In Python 3, if I do it wrong, I get an easy-to-debug TypeError. For bonus points, if I use Mypy, I can get that error without even having to run the code.

Re: Numpy: Plan for dropping Python 2.7 support

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

If this is the case then wouldn't re-naming it Python 4 shake the negative view of it? Guess it's too late now for Python but I've seen it done in other open source projects and it worked pretty well.

"Python 4?? People have not even migrated to Python 3 yet!"

Re: Numpy: Plan for dropping Python 2.7 support

#68
post #59
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. 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.

Sure, but—as other people mention down-thread—there are still COBOL programs, and even COBOL (maintenance) developers. There's just no community for active, new COBOL development. That's what it means for a language to be EOLed.

Re: Numpy: Plan for dropping Python 2.7 support

#69
This is great news. I've been working with Python 3 for a few years now, and it really is a nicer language than 2. Granted 2.7 is a hard act to follow.

Even though the transition from 2 to 3 has been slow, I take it as a positive sign about the Python ecosystem. The general Python community has traditionally erred toward stability, and conservative feature introduction. The gradual introduction of large changes to the core language reflects that characteristic.

Hopefully this will cajole Python 2.7 users to migrate. Assuming you have decent test coverage, the migration generally isn't that difficult.

If you do a lot of NLP or string processing, the sane unicode support is worth it alone.

Re: Numpy: Plan for dropping Python 2.7 support

#70
post #27

Earlier quoted context omitted.

> 2 is pretty old, it's time to move on. Why? Just because "it's pretty old?" The 2-to-3 change seems mostly cosmetic. When Python users ignored 3, Python devs started flogging their dead horse. When the horse still refused to move, disappointed riders started shouting "shame!" at users who suggested that the horse looked dead. Eventually, the riders tied ropes to the horse and pulled it along the ground. The onlooke…

That's a very melodramatic comment for someone who clearly hasn't been keeping track of the 3.x changelogs – which pretty much all contain at least one compelling update to the language. Modern Python is v3. Legacy support drop-off is the same with any project.

I was going for "humor" more than "melodrama," but maybe I failed at both... The actual breaking changes between 2.x and early 3.x struck me as cosmetic and pointless.

To compare: Perl went one way by breaking everything to essentially make a new language, and failed to get people to switch; C++ bent over backwards to maintain compatibility, and failed to fundamentally evolve the language. Python basically failed in both ways, changing the language just enough to break most people's code, while changing it too little to effect significant change. It combines most of the disadvantages of both backward compatibility and novelty, with few of the advantages of either.

Post reply on HN