Live data from Hacker News

Numpy: Plan for dropping Python 2.7 support

github.com

81–90 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#81

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 too felt 7 bit ascii was a good thing, and I believe I know members of the original ANSI committee who worked on it.

But, I now live and work in the Asia-Pacific region, and I regularly interact with data and content which is not represented in 7 bit ascii. This has altered my perspective.

My comrades from 7 bit land also migrated into a world of homophones. It is entirely true you can get into some awful places regarding what things look like and what semantically they mean, but the one thing that has never come up, is what errors of handling it introduced into the code: the code, is doing what it does. It is how you interpret it, that has to change.

uStrings just work. Unclench your Undead fists, and accept the news from your brothers and sisters outside of paper tape.

Re: Numpy: Plan for dropping Python 2.7 support

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

I think there were also more compatibility issues prior to 3.3 (when they started allowing u"") for libraries that did want to support both. It seems like the core team predicted that the most popular migration path for libraries would be `2to3` or something like that, when in fact the single-codebase-supporting-both strategy has been much more popular? Probably the transition would've been easier if everyone had see…

That's correct. If something like "six" would have been provided as part of 3.0, things would have went more smoothly. There could have been some language changes in 3.0 to make single-codebase easier. It was only later that the core developers realised that would be the normal way for libraries to support Python 3 (e.g allowing u prefix on strings in 3.x). Quite a bit of time was wasted while this got sorted out. Things are a lot better now. Soon, I think most people will stop worrying about 2.x backwards compatibility.

Re: Numpy: Plan for dropping Python 2.7 support

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

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.

Re: Numpy: Plan for dropping Python 2.7 support

#85
post #54
post #12

Earlier quoted context omitted.

Python 2 came out in 2000 and goes EOL 2020 I think. Perl 5 was released in 1994 and has no planned EOL date, so it is currently winning by a fair margin.

And 2 vs 1 is really only a licensing issue. Python 1.4, from 1996, is not so different!

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.

Re: Numpy: Plan for dropping Python 2.7 support

#87
post #82

Earlier quoted context omitted.

I think there were also more compatibility issues prior to 3.3 (when they started allowing u"") for libraries that did want to support both. It seems like the core team predicted that the most popular migration path for libraries would be `2to3` or something like that, when in fact the single-codebase-supporting-both strategy has been much more popular? Probably the transition would've been easier if everyone had see…

That's correct. If something like "six" would have been provided as part of 3.0, things would have went more smoothly. There could have been some language changes in 3.0 to make single-codebase easier. It was only later that the core developers realised that would be the normal way for libraries to support Python 3 (e.g allowing u prefix on strings in 3.x). Quite a bit of time was wasted while this got sorted out. Th…

> Soon, I think most people will stop worrying about 2.x backwards compatibility.

Numpy is certainly not the only project with a plan to sunset Python 2 support: http://www.python3statement.org/#sections30-projects

Re: Numpy: Plan for dropping Python 2.7 support

#88

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.

Re: Numpy: Plan for dropping Python 2.7 support

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

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 security and bugfixes), and code using your PS/2 keyboard...

Re: Numpy: Plan for dropping Python 2.7 support

#90
post #44
post #7

That’s about the same time python 2 support drops in general. Sounds strange to support packages after the underlying python has moved on. Kudos to the numpy team for writing the most awesome python module under the sun, and for providing great support!

It's not strange. Python developers might declare Python 2.X EOLed, but that won't stop people from using it. Like it or not, Python 2.X is not going away.

There are big companies with huge legacy 2.x codebases who will stall as long as possible. But popular libraries are dropping 2, and many new libraries aren’t supporting it to begin with. Python 2 is accelerating toward irrelevance.
Post reply on HN