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

291–300 of 733 posts

Re: Sunsetting Python 2

#291

Post by liveoneggs »

VBprogrammer wrote: post #38
d--b wrote: 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).

As someone who works on a 99% Python 2 codebase I think this is a very necessary step. Hopefully one of our larger customers will realise we are still running their critical infrastructure on Python 2 and make enough of a fuss that we can justify the expense.

even if you do the same thing will happen with python 4; these languages are not built with long term stability in mind

Re: Sunsetting Python 2

#292

Post by ryl00 »

ueiuestu wrote: post #260
jedberg wrote: post #62

In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet. In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now. For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backi…

This makes me wonder, are there any software frameworks and languages that are specifically built for multi decade use? Where they only release security updates and no breaking changes?

I think there are plenty of programming languages (maybe even most of them?) which take backward compatibility as a very serious goal. Obviously there's a balance between "don't break user space!" and fixing major problems (e.g., C's gets()), and most of the major ones seem to lean toward the former.

At the company I work at, we've got a large amount of Fortran code from the '70s that works fine with the latest and greatest Fortran compilers (barring deprecation warnings which help guide refactoring efforts). Same with C/C++ from the '80s.

Re: Sunsetting Python 2

#293

Post by toyg »

tibbon wrote: post #261

One thing that confuses me about Python is just how many projects don't specify if the app is supposed to use 2 or 3, and the correct answer isn't 'either'. Check out something from Github, only to find I actually do need Python 2.7 or something. Is it that Python developers assume everyone will just intuit the version, or is there a default?

Rule of thumb is that no version == python2, either because it pre-dates 3 or because the developer's concept of python is "what happens when I type python at the shell" so it's still 2. It's often a big red flag about quality; competent Python developers find it natural to state py3 support upfront (or lack thereof) because they know it matters.

Re: Sunsetting Python 2

#294

Post by wiradikusuma »

ofibrvev wrote: post #267
ken wrote: post #240

Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece. (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Dependenc…

> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg,…

I think this is where paid support comes into picture. Volenteers can keep improving Python, business that cant/wont upgrade can pay someone to "handle it", and consultants can make money. Everyone is happy.

Re: Sunsetting Python 2

#295

Post by cdelsolar »

JeremyBanks wrote: post #236
voldacar wrote: post #228

Earlier quoted context omitted.

And I would add - symlinking or shell aliasing does not count! I want a linux system without a single python2 binary anywhere on the disk! How many more decades must we wait??

Hopefully never. If I have a modern C compiler, I can still run most C code from 30 years ago. When I have a Rust 2030 compiler, I'll still be able to run Rust 2015. But with only a Python 3 interpreter, I'm strictly unable to run the vast majority of Python code out there.

the "vast majority"? do you have evidence for that?

Re: Sunsetting Python 2

#296

Post by mikepurvis »

shakna wrote: post #124
reitzensteinm wrote: post #95

Earlier quoted context omitted.

Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short. Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.

Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes. Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.

It's interesting seeing who the holdouts are, though. Less than a year ago, the CEO of Sentry (the crash reporter) locked a Github thread with essentially "we'll get there when we get there, sometime in or after 2020." But then, as late as 2016 their stance was pretty much that they would never migrate, so I suppose it's not surprising that they aren't super prepared for it:

https://github.com/getsentry/sentry/issues/8806#issuecomment...

https://github.com/getsentry/sentry/issues/1152#issuecomment...

I mean, even supervisord is migrated at this point, and it was a long-time laggard.

Re: Sunsetting Python 2

#297

Post by metasyn »

ssully wrote: post #288

On the topic of large companies still using Python 2, I would love to hear about Splunk's upgrade plans. They have the following[1] on their SDK page about upgrading, but my understanding is their entire platform is still on Python 2. I've upgraded a number of projects at my work to Python 3 this year, but nothing that 2-3 developers couldn't do in a few weeks. Can only imagine the headache of migrating something the…

Granted I don't work at Splunk anymore, but did recently. They were definitely working hard on migrating everything to python3, and if I remember, they had a planned roll out where python2/python3 would co-exist.

However, if you've been using the python SDK for Splunk - its been supporting python3 for a few years already (https://github.com/splunk/splunk-sdk-python/commit/4503db961...)

See this blog post: https://www.splunk.com/blog/2019/07/01/admins-and-developers...

And this helpful doc: https://docs.splunk.com/Documentation/Splunk/7.3.1/Python3Mi...

Re: Sunsetting Python 2

#298

Post by voldacar »

JeremyBanks wrote: post #236
voldacar wrote: post #228

Earlier quoted context omitted.

And I would add - symlinking or shell aliasing does not count! I want a linux system without a single python2 binary anywhere on the disk! How many more decades must we wait??

Hopefully never. If I have a modern C compiler, I can still run most C code from 30 years ago. When I have a Rust 2030 compiler, I'll still be able to run Rust 2015. But with only a Python 3 interpreter, I'm strictly unable to run the vast majority of Python code out there.

Then you can freely make the choice to install one from your package manager. Don't force your cruft on my system though.

Re: Sunsetting Python 2

#299

Post by WilliamEdward »

bandrami wrote: post #153
WilliamEdward wrote: post #39

Earlier quoted context omitted.

Why would anyone like python2 so much better than python3 that they would want to fork it into its own language? The two languages are already incredibly similar and python3 has a much larger active community.

Because I have 20-year-old code in the wild still running. I know python won't change out from under me; I do not have that confidence in python3.

This doesn't make sense; if python 2 continues being developed then it will change for you. Besides, no one says you have to upgrade if you've found a version of 3 that you like, so what exactly is changing out from under you? The leap from 2 to 3 was not even that drastic. The entire changelog is incredibly short.

Re: Sunsetting Python 2

#300

Post by WilliamEdward »

jiffyjeff wrote: post #144
mehrdadn wrote: post #132

Earlier quoted context omitted.

Probably because it's hyperbole to get a point across.

I don't know if the author was intending to be hyperbolic -- I for one prefer Python 2's print. I would've preferred keeping print the way it was and using a new keyword for the new functionality.

I still don't see why the print function justifies trying to keep the language alive. You don't prefer that print act as a function and not a keyword? Maybe you don't, but is the change really not worth giving up 2?
Post reply on HN