Live data from Hacker News

Sunsetting Python 2

python.org

71–80 of 733 posts

Re: Sunsetting Python 2

#72
post #18

Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a long time. Since the stuff is open source, wouldn't it be nicer if it was possible to fix a bug if needed? Not saying that it should be actively worked on. But maybe one person could be appointed to look over bug fix pull requests (which shouldn't be that frequent these days).

Many systems still run COBOL today

The latest official COBOL spec is COBOL 2014 and there are at least two or three competing companies out there that will happily sell you up to date COBOL tools and compilers. So while COBOL may be old, there are still new 'exciting' things happening in the COBOL space.

Re: Sunsetting Python 2

#73
post #4

Earlier quoted context omitted.

No, the benefit of FOSS is that if the group developing a product does not support it anymore, you are free to fork it and support it yourself. And I am sure we will see a fair share of people doing that. What I am not sure is of anyone doing so will have the shoulders to actually support it. Python 2.7 was released 1 decade ago. That's quite a long transition time.

Tongue in cheek comment; C was released 47 years ago and is still supported... but then again, that shows a very different philosophy between system languages and scripting languages.

Not really. :-)

ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.

Re: Sunsetting Python 2

#74

Earlier quoted context omitted.

Tongue in cheek comment; C was released 47 years ago and is still supported... but then again, that shows a very different philosophy between system languages and scripting languages.

Not really. :-) ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.

touché :)

Re: Sunsetting Python 2

#75
post #5

Earlier quoted context omitted.

I honestly don't believe that many will step up and take over. Many will complain, but few will do the actual work. Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.

Ubuntu 18.04 has support for Python 2.7 til 2028 I think.

Only for paying customers, general support will end in 2023.

Re: Sunsetting Python 2

#76
post #18

Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a long time. Since the stuff is open source, wouldn't it be nicer if it was possible to fix a bug if needed? Not saying that it should be actively worked on. But maybe one person could be appointed to look over bug fix pull requests (which shouldn't be that frequent these days).

COBOL has an upgraded version? Besides, legacy is not a perfect excuse for using python 2 since it's so similar to 3 and with some amount of effort you could port it over quite easily.

COBOL has an upgraded version?

Latest version of the COBOL standard is COBOL 2014 (AKA the same year python 3.4 was released).

Re: Sunsetting Python 2

#77
post #4

Earlier quoted context omitted.

No, the benefit of FOSS is that if the group developing a product does not support it anymore, you are free to fork it and support it yourself. And I am sure we will see a fair share of people doing that. What I am not sure is of anyone doing so will have the shoulders to actually support it. Python 2.7 was released 1 decade ago. That's quite a long transition time.

Tongue in cheek comment; C was released 47 years ago and is still supported... but then again, that shows a very different philosophy between system languages and scripting languages.

That's not really a fair comparison. Python 2 probably _will_ be supported for decades to come, just not necessarily by the PSF. I'm sure that 99% of people and organizations supporting C 40 years ago do _not_ support C today.

Re: Sunsetting Python 2

#78
With the sunset date passing, Python 2 is going to become a niche while still having a massive install base.

There's a lot of money to be made doing migrations and keeping the beast itself alive.

Re: Sunsetting Python 2

#80
"What will happen if I do not upgrade by January 1st, 2020?" "You will lose chances to use good tools because they will only run on Python 3, you will slow down people who depend on you and work with you."

The tone in this document is excessive and over-the-top. If the author spent half the document demonstrating (with examples) why Python3 is so great, it might actually be useful and get people upgrading like right now as they're reading it. But instead, it seems the author simply wanted to convey how sick they are of Python 2. The author does not appear to understand their users; that's their real frustration.

In life outside of Python... The transition in C/C++ from C++98 to C++11 and then C++20 (and beyond) has been quite clean and professional. There were some glaring issues with C++11 that later got patched up (e.g. rvalues but no optional, no filesystem, make_unique, etc). Most importantly, compiler support and standard distributions improved a lot. There were often clear incentives to upgrade, and it was relatively easy to stick to an old standard where necessary.

In contrast, Python has become a bit fractured, with a number of notable well-discussed but unaddressed loose ends in Python3: http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...

I think the Python community has failed to present strong enough incentives for upgrading to Python3, and that's why users are sticking to Python2 and 'slowing everybody down'. The jump to C++11 was obviously needed: at the very least, `auto` saved much of your sanity and you no longer really needed to include Boost in your build. But you could stick to an old standard if you wanted; you could even transition a codebase module-by-module in some cases.

The Python3 community seems to have been groping for a similar killer feature (e.g asyncio, as discussed in Amber Brown's talk above), but the value-add isn't so clear. `six` is honestly a nice catalogue showing how many changes in Python3 are largely sentimental.

Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.

Post reply on HN