Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sunsetting Python 2

python.org

Post reply on HN
Print view View original

351–360 of 733 posts

Re: Sunsetting Python 2

#351

Post by [deleted] »

radlad wrote: post #333
theelous3 wrote: post #65

Earlier quoted context omitted.

Likely the case. A lot of foot dragging took place. By five years ago most things of use were py3, conversion was easier than ever (and easy enough). More importantly, it would have stopped piles and piles of bleakly futured py2 codebases being written. That people were still writing new py2 code five years ago is terrible, and the long sunset is certainly greatly at fault here. That people are still writing new py2…

I'm pretty sure Twisted(!) did not have Python 3 support 5 years ago. Also, macOS _still_ only ships with Py2. If I'm writing a quick script for my girlfriend to make her life easier, should I target Python 3 and force her to learn how to install xcode so she can learn to use homebrew so she can install Python 3, or should I just target Python 2 and move on?

[deleted]

Re: Sunsetting Python 2

#352

Post by falcolas »

coldtea wrote: post #3

> If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team i…

Not just RedHat - Google and Amazon have LTS that they're providing that will most likely include some flavor of 2.7.

Google has flat-out stated that they will continue to support 2.7 in App Engine for an undefined period of time.

Amazon has inferred through their Amazon Linux 2 LTS support page that Python 2.7 is included in that support for 3 more years.

Re: Sunsetting Python 2

#353

Post by dna_polymerase »

dahart wrote: post #331
lvh wrote: post #268

Earlier quoted context omitted.

One of the easiest compared to what? Certainly not a Python point release. A couple of points: 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. 2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining. (I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came…

Python 3.1 came out 10 years ago. 3.2 was released in 2011. What does that mean about the complaints since, let’s just say 2015 to be fair?

I heard several people saying that 3.6 was the first Py3 worth transitioning to. Largely for async (I think async/await came to live then). There is this take on performance: https://hackernoon.com/which-is-the-fastest-version-of-pytho...

Re: Sunsetting Python 2

#354

Post by weberc2 »

mikepurvis wrote: post #334
weberc2 wrote: post #327

Earlier quoted context omitted.

No one is arguing that upgrading would be trivial; the argument is that it's necessary work that could have been started 10 years ago. Also, if you run your unit tests on Python 2 and 3, you'll get pretty good pretty fast at writing 2-3 compatible code.

The comment I was specifically replying to asserted that "you could easily write Python 3 compatible code", and could have been doing so 10 years ago. This is simply untrue— there are a dozen small stumbling blocks that mean that writing bilingual code has a real cost. And it's not as easy as just having the right CI setup, especially if it's ten years ago and most of your dependencies haven't migrated.

Ah, I see the confusion. In this case, "easily" is relative. The assertion "you could easily write Python 3 compatible code" was in response to the (implied?) assertion "you can't do anything to migrate unless your dependencies are migrated". Perhaps "simply" would have been a better word choice than "easily". To your point, writing 2-3 compatible code has a real cost, but to the GP's point, it's the obvious solution to the "can't do anything until deps are migrated" problem.

Re: Sunsetting Python 2

#355

Post by ajayyy »

MrStonedOne wrote: post #154
coldtea wrote: post #3

> If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team i…

Exactly! I am getting tired of FOSS orgs thinking they can speak for their entire extended community. `PSF` should be inserted before every occurance of the word volunteer in that page.

They manage merging though, so it has to be a fork.

Re: Sunsetting Python 2

#356

Post by floatingatoll »

falcolas wrote: post #352
coldtea wrote: post #3

> If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team i…

Not just RedHat - Google and Amazon have LTS that they're providing that will most likely include some flavor of 2.7. Google has flat-out stated that they will continue to support 2.7 in App Engine for an undefined period of time. Amazon has inferred through their Amazon Linux 2 LTS support page that Python 2.7 is included in that support for 3 more years.

[resolved]

Re: Sunsetting Python 2

#357

Post by floatingatoll »

radlad wrote: post #333
theelous3 wrote: post #65

Earlier quoted context omitted.

Likely the case. A lot of foot dragging took place. By five years ago most things of use were py3, conversion was easier than ever (and easy enough). More importantly, it would have stopped piles and piles of bleakly futured py2 codebases being written. That people were still writing new py2 code five years ago is terrible, and the long sunset is certainly greatly at fault here. That people are still writing new py2…

I'm pretty sure Twisted(!) did not have Python 3 support 5 years ago. Also, macOS _still_ only ships with Py2. If I'm writing a quick script for my girlfriend to make her life easier, should I target Python 3 and force her to learn how to install xcode so she can learn to use homebrew so she can install Python 3, or should I just target Python 2 and move on?

macOS says they’ll stop supporting scripting languages out of the box someday, so targeting Homebrew is probably best.

Re: Sunsetting Python 2

#358

Post by zurtex »

kortilla wrote: post #320
radlad wrote: post #312

Earlier quoted context omitted.

> Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. I would expect any stable release of software to be "good and ready." Can you explain what was wrong with Python 3.0 and 3.1? > core dev did not listen to any of the problems people pointed out for _years_ What problems were those?

Strings in python3 were terrible for memory well into mid-3. Raymond Hettinger is a core dev and he recently stated on Twitter that he didn’t feel py3 was a clear upgrade win until this most current release.

Raymond has been consistent in saying Python 3.6.1 was the release where Python 3 became better than Python 2. That was March 21, 2017, and we're now in Python 3.7.4.

I appreciate the general point that that's far more recent than Python 3s initial release but it's also a large exaggeration to say "until this most current release".

Also to understand why it took so long is because Python 2 kept improving after Python 3s release. Python 2.7 was a great release and many further features from Python 3 got backported in it's 2.7.x point release.

Re: Sunsetting Python 2

#359

Post by coliveira »

That's why Python receives a bad name, and for a good reason. Nobody is telling people who use Java since version 1 that they need to upgrade code if they want to continue using the language. The code just works, and will continue to work as long as there are compilers for Java. The same thing about C and C++, these languages introduce new features as times evolve, but they still allow users to retain their investment in old code. This is not the case with Python. Because of some bad design decisions, they inflicted pain on their users for more than a decade to force them into choosing one version or another. And now they are deprecating a version of the language that is still used by millions of people, causing again more trouble. Why in the world they need to deprecate this code when there are millions of people who use it all day long? I still see lots of code continuing to be written in Python 2, and all this code will have to be rewritten just because of some bad design and implementation decisions of a few people developing this language.

Re: Sunsetting Python 2

#360

Post by Kaiyou »

ilikehurdles wrote: post #286
marcus_holmes wrote: post #233

Earlier quoted context omitted.

This attitude is ridiculous. I'm supposed to go and tell all the various projects that I depend on that they have to change their upgrade timescales to suit mine? Even if I had enough time to help them all meet that kind of timescale, why would they agree to fit their changes into my required deadline? Maintainers are under a lot of pressure. Having users come along and say "we'll add 50 developers to your project if…

You fork the library. You fix the incompatibility issues. You issue PRs back to the mainline to help them adopt the same fixes. At some point in the future you can switch back to the main repo if they've migrated, or you can consider that library abandoned and continue to maintain your own or find an alternate. At no point do you have to wait on anyone else, you choose to .

You can do that, but then they won't accept your solution, so you just spend time developing a parallel system that you need to support yourself until the end of time. Been there, done that.
Post reply on HN