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

591–600 of 733 posts

Re: Sunsetting Python 2

#591

Post by CDSlice »

pudquick wrote: post #394
salamanderman wrote: post #304

My new Mac laptop in 2016 came installed with Python 2.7 from Apple. It's that kind of subtle defaults that I think slowed the transition. I didn't want to change the system Python.

In 2016, that laptop also came with System Integrity Protection - you couldn't change /usr/bin/python if you wanted to. And you still can't to this very day. Changing System-provided python was always against recommendations in prior OS versions because the next OS update could re-replace it at any time. I agree that it probably contributed to python 2 inertia as it was re-exposing people to the idea that "typing pyt…

Actually you _can_ disable SIP and replace use/bin/Python, but that is a Very Bad Idea.

Re: Sunsetting Python 2

#592

Post by joshuamorton »

gridlockd wrote: post #578
sametmax wrote: post #544

Earlier quoted context omitted.

The science stack is also the one that starting migrating the earliest. Hell, numpy started supporting Python 3 eight years ago, while five years ago people were still complaining so much they got the EOL delayed. Not saying there are not some specific things that were late or never happened, but again, they are about a minority of projects. The thing is this minority is making all the noise. Given the reach and popu…

> The science stack is also the one that starting migrating the earliest. ...but the last to actually finish migrating. In fact, it's still ongoing. > Given the reach and popularity of Python, of course you will always find plenty of testimonies saying they suffered Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase. Everyone had to use an inferio…

Which common parts of the science stack are still partially two-only?

Conda ships on 3.7, and I'd consider it the definitive "scientific" stack.

Re: Sunsetting Python 2

#593

Post by joshuamorton »

logifail wrote: post #464
weberc2 wrote: post #354

Earlier quoted context omitted.

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 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 Q: Ten years ago how would you have explained to your manager that you needed your team to start writing 2-3 compatible code, which obviously takes considerably more time and effort than sticking with 2 compatible code?

It doesn't take considerably more time.

At this point, all the code I write is 2/3 compatible, and the things that annoy me are all py3 only features. Backwards compatibility stuff is pretty easy. Most of the easy problems are easy, and six has solved all the hard ones for like 7 years.

And I've been writing some of my code 2/3 compatible since 3.4.

Re: Sunsetting Python 2

#594

Post by flukus »

sametmax wrote: post #508
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…

By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones.…

> Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy.

In my very brief experience with python over the last few weeks this is very common. Half of our dependencies were abandoned before python 3 existed, when mercurial shuts off the hg we'll even lose the source to some of them. Python 3 get's the blame but the real problem is that the company has ignored maintenance for decades, it's entirely there own fault. There's no "business value" in maintenance until the whole lot needs to be rewritten.

Another underlying cause is package tools like pip, they make it too easy to take on dependencies with zero thought given to their maintenance windows and management think the can just ignore upgrading/replacing them regularly.

Re: Sunsetting Python 2

#595

Post by kortilla »

zurtex wrote: post #358
kortilla wrote: post #320

Earlier quoted context omitted.

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…

Sorry, I misremembered. 3.8 is the first one he said is a clear winner: https://twitter.com/raymondh/status/1167218640095043586

Re: Sunsetting Python 2

#596

Post by kortilla »

mindcrime wrote: post #477
kortilla wrote: post #317

Earlier quoted context omitted.

Well it’s a shitty analogy because a swap to torx is basically a single API change. The switch to py3 is more akin to using a new building material. Easy to start with once you know the differences, but it’s a bitch to retrofit if you depend on a method of construction incompatible with it. “Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.

Most non-tech businesses have no budget for that kind of tech debt work. That's fine. I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make. Now they have to be responsible for the outcome(s) of their choices.

Using python2 is in no way similar to going without fire insurance. There are internal-only apps that will run fine for decades to come with no risk to the business on py27.

There are many maintenance mode projects where the switch to 3 represents absolutely no upside and is all downside risk. Not everyone is developing web apps in constant flux that are exposed to the Internet. That is a tiny fraction of python’s use cases.

Re: Sunsetting Python 2

#597

Post by mynameisvlad »

protomyth wrote: post #589
WorldMaker wrote: post #548

Earlier quoted context omitted.

Would PSF exponentially increasing support and maintenance costs for Python 2 into multimillion dollar contracts and bundling over-margined hardware in with the bundle to make it more of an IBM-like transition help?

Yep, someone has to pay in one way or another like Red Hat customers on 7, but to say Python has near the life cycle of COBOL is just disingenuous. Old COBOL still runs, but Python 2 programs will not. It really shows what the achievement languages like COBOL, RPG, and Fortran are in terms of longevity and migration.

> but Python 2 programs will not

Er, why not? It's not like there's some kill switch in Python 2 that will make it stop working after January 1st, 2020. If it works now, then it'll still work, you're just not guaranteed fixes anymore. At least, not for free. As stated in the article, paid support options exist from several vendors.

Re: Sunsetting Python 2

#598

Post by kortilla »

mindcrime wrote: post #517
gridlockd wrote: post #514

Earlier quoted context omitted.

"Hey boss, we're gonna use this hip new language that will break everything for no good reason a few years down the line." Congratulations. You're fired.

"Hey Joe, why did our customer database get leaked and published on a dark-net site?" "Hey boss, we're using an outdated programming language for which security updates are no longer provided, because we were told there's no budget for fixing technical debt." "Congratulations, you're fired." Same outcome either way... might as well make some effort to do the right thing along the way...

You’re confusing runtimes with the language. Py27 as a language has no security flaws that would allow a database to get leaked.

People will continue to use py27 going forward with likely a pay-for-support runtime because that’s cheaper and less risky than changing a million lines of python code.

Re: Sunsetting Python 2

#599

Post by mynameisvlad »

inatreecrown2 wrote: post #395
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…

you are comparing an open source language to the apple os.

Yes, and? GP was very clear that this is a comparison to show how quickly it can be done when it's proprietary and not open source.

Re: Sunsetting Python 2

#600

Post by mynameisvlad »

sixothree wrote: post #196
drej wrote: post #159

What surprises me about this is that the documentation for Python 2 does not explicitly say that the language version is about to be unsupported, see e.g. https://docs.python.org/2/library/zipfile.html Contrast this with the Postgres website, which tells me I'm browsing old docs (because Google still offers old links), see e.g. https://www.postgresql.org/docs/9.2/tutorial-window.html Are there plans to add a banner t…

HL7.org has a banner on every version of the FHIR spec with a different message depending on the version. http://hl7.org/fhir/

I would discourage this, as it will lead to banner blindness. Only pop a banner up if you want the user to read and react to it. Otherwise, they'll just get used to the banner being there and will often times not read it at all.
Post reply on HN