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

671–680 of 733 posts

Re: Sunsetting Python 2

#671

Post by alexhutcheson »

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…

[not speaking on behalf of any employer, opinions my own]

I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Even if it only takes ~5 minutes per module to make the changes and validate that it works correctly, this becomes a giant undertaking when you have tens of thousands of files to migrate.

The fact that it takes a long time also creates other problems. Your business isn't going to hit "pause" on other development, so there will be changes constantly introduced into modules you've already "swept". It's going to be hard to make sure 100% of your engineers and code reviewers are knowledgeable about the specific requirements to make sure the code works in both 2 and 3, so you would really like some automated safeguards to make sure they don't introduce anything that won't work in 3. Pylint helps with this, but won't catch everything. Unit tests are obviously essential, but:

1. Even a well-tested project won't have tests that cover 100% of code paths and behavior.

2. You're stuck running the tests on both python2 and python3 for the duration of the migration, which doubles the resource (compute, memory, etc.) cost of your Python CI and regression testing infrastructure for the duration of the migration.

I see far too many commenters attributing the delayed migration to laziness or complacency. In reality, most big companies have passionate Python advocates who really want to be on Python 3, but the scale of the problem and the lack of tooling to tackle it with a sub-O(n) amount of effort make the overall project risky and expensive for the business.

Re: Sunsetting Python 2

#673

Post by _fizz_buzz_ »

Kaiyou wrote: post #311
mffnbs wrote: post #270

Earlier quoted context omitted.

Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.

Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.

We sell welding systems to weld stainless steal, copper pipes, etc. We always give a warranty of 24 month, guarantee paid support for 10 years, and support older machines only if possible. I am not sure which industry you are talking about, but 60 years is the exception in my experience.

Re: Sunsetting Python 2

#674

Post by [deleted] »

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.

[deleted]

Re: Sunsetting Python 2

#676

Post by partialrecall »

carapace wrote: post #609
partialrecall wrote: post #507

Earlier quoted context omitted.

Making them use a name other than python is hardly any great hardship. Mozilla maintains their trademark too and nobody whines to hard about that. Just call it "boa" or something. Firefox->Icecat.

> Making them use a name other than python is hardly any great hardship. It wasn't. (And Tauthon is arguably a really cool name.) But it does indicate that they want Python 2 dead. > Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Py…

> But it does indicate that they want Python 2 dead.

Being less uncharitable, it indicates they want to avoid brand dilution (which is wholly reasonable.)

Re: Sunsetting Python 2

#677

Post by linuxftw »

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…

If you were writing major libraries that needed to work on both 2 and 3 like many of us were, I suspect your opinion would be different. It was never a case of 'oh we'll just switch to 3 now' because that's not at all how it worked.

> If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.

Yeah, right. Look at the creator of Python himself. Took about 3 years to migrate just his employer, and that's a top-tier software shop [1].

I've heard many people talk like you over the years, always being dismissive of the cost to others in python 2 vs 3. The complaints against the migration were not unfounded.

1: https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one...

Re: Sunsetting Python 2

#678

Post by swebs »

When will OS vendors stop defaulting `python` to Python 2? It seems like an unnecessary trap that pushed new developers to an out of date version. Even Ubuntu 19.04 defaults to Python 2.7.16

Re: Sunsetting Python 2

#679

Post by protomyth »

mynameisvlad wrote: post #597
protomyth wrote: post #589

Earlier quoted context omitted.

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.

Any software in the modern era that isn't upgraded for new OSes or security patched is dead.

Re: Sunsetting Python 2

#680

Post by protomyth »

C1sc0cat wrote: post #658
protomyth wrote: post #589

Earlier quoted context omitted.

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.

You can still run 1960's code today for both COBOL and Fortran - I suspect some Fortan 2 oddities might not work I am thinking of the sense commands

Probably, but the care the Fortran folks take to not break anything but still evolve a modern language is amazing.
Post reply on HN