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

541–550 of 733 posts

Re: Sunsetting Python 2

#541

Post by dralley »

bscphil wrote: post #432
mikepurvis wrote: post #296

Earlier quoted context omitted.

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…

Calibre is another well known case, and they don't plan to migrate. Actually, I can't wait to remove it from my hard drive on Jan 1, since it's one of the most poorly designed apps I've ever used. It's really not surprising at all that they're not able to migrate it, assuming the quality of the app is indicative of the quality of the code. I wouldn't be surprised if the same was true of a lot of applications that are…

Calibre is, in fact, migrating. There are at this point dozens of commits over the past few months to that goal. Not sure what changed his mind.

Re: Sunsetting Python 2

#542

Post by dragonwriter »

kortilla wrote: post #317
sdoering wrote: post #250

Earlier quoted context omitted.

> If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often. > Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. D'accord. Exactly. I had very fruitful d…

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.

> “Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.

Every non-tech business that maintains technical infrastructure finds itself doing that kind of tech-debt work regularly (if, often, chronically behind the vendors recommended schedule) for every platform they use Py2 to Py3 may (or may not, really) have been a bit more painful than a (multistep, because those types of shops never do it timely enough that a single-version-bump makes sense) .NET framework, Visual Studio, SQL Server, and Windows Server upgrade (and, yeah, those often happen together as multistep upgrades in slow enterprise shops), but it's not a fundamentally different kind of problem (and replacing dependencies that didn't make the same upgrade, often because they were abandoned years before the firm made it's upgrades, is often a part of that.)

Re: Sunsetting Python 2

#543

Post by nickjj »

guitarbill wrote: post #436
nickjj wrote: post #328

I'm happy this finally happened, even though I've been clinging to Python 2.7 for quite some time. I run a Flask course[0] and from the beginning I coded the app to work for both 2.7.x and 3.x in parallel but it's only been a few months now where Celery supported Python 3.7. In either case, upgrading from 2.7.x to 3.7.x was super painless. It came down to making sure Celery is using 4.3+ and pytest requires 5+ if you…

pytest has has python 3.5+ support for a while, even 4.0.0 supported it: https://pypi.org/project/pytest/4.0.0/ . although the recent pytest changes are well worth picking up!

> pytest has has python 3.5+ support for a while, even 4.0.0 supported it: https://pypi.org/project/pytest/4.0.0/ . although the recent pytest changes are well worth picking up!

Yes but check the changelog for pytest.

Version 5.x.x is only available for Python 3.5+. They dropped support for 2.7 and <= 3.4, unless you fall back to the 4.6 series.

Re: Sunsetting Python 2

#544

Post by sametmax »

gridlockd wrote: post #518
sametmax wrote: post #508

Earlier quoted context omitted.

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.…

The entire science stack is "terrible C extensions". This is also the kind of tight-budgeted stuff that needs relatively rare Python/C developers, not just your average overpaid Python web developer. I'm not saying we would've cured cancer if people didn't have to deal with this bullshit, but it's definitely a setback.

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 popularity of Python, of course you will always find plenty of testimonies saying they suffered. Again, it's important to remember you can't make everybody happy, especially if your job is important. If porting is easy for 90% of projects, you did a great work, period. 10% of millions of users having it hard is still going to raise a lot of voices against you by the sheer power of numbers, but you did ok.

There is also dishonesty. Most people reporting this problem or that problem didn't actually encounter it. They are reporting somebody else experience they heard about because they wanted to make a point. Or vaguely tried something and ran away after they saw 10 minutes of fiddling didn't solve it.

In 10 years going from company to company, I met only 2 projects that were hard to port, but much, much more complainers. When I looked at what was really going on, the fact was just that they were afraid to port, and so just repeated all the stuff other people told them would go wrong. Or they tried running a few scripts for 5 minutes on Python 3 and gave up seeing too many error messages.

I know there are honest situations in the lot. But again, the most honest people are not making noise, because they just ported their code and noticed it wasn't the hardship they've been told.

Re: Sunsetting Python 2

#545

Post by pbreit »

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…

Totally disagree. There's rarely a good reason to break backwards compatibility. It's beyond rude to choose to break compatibility and then force all your users to fix it.

The Apple comparison is a bad one since Apple controlled the whole thing.

Re: Sunsetting Python 2

#546

Post by WorldMaker »

pnathan wrote: post #515
dna_polymerase wrote: post #353

Earlier quoted context omitted.

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...

The Py3 string handling was beyond frustrating prior to 3.6. For what I do, Unicode complexity is not required. Having to stuff it into everything was more trouble than it was worth.

The ubiquity of emoji alone mean that Unicode is everyone's problem in 2010+, and ignoring it won't make it go away. It's Python 2.x where dealing with Unicode (which is everywhere) is far too complex, and more trouble than it is worth. The "complexity" of Python 3 string handling is worth it, and no worse (even < 3.6) than any other modern programming language, and possibly easier than some by making clear runtime errors where accidents are easiest to make. (Though arguably, perhaps I'm biased by having done plenty of Unicode work in other languages that Python 3 did seem so familiar and easy from the start for my Unicode needs. Your mileage of course varies, we all have different backgrounds.)

Re: Sunsetting Python 2

#547

Post by your-nanny »

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.

well what if your best guess was that py2 would never actually be deprecated. Certainly in the early tens I had serious doubts.

Re: Sunsetting Python 2

#548

Post by WorldMaker »

protomyth wrote: post #528
jhall1468 wrote: post #513

Earlier quoted context omitted.

You mean, IBM does quite a good job of making sure IBM COBOL is supported long term. They are maintaining their compiler, which is exactly what PSF is doing. They are maintaining their interpreter, which is Python 3.

The GP post missed the fundamental difference between keeping COBOL running and keeping Python 2 running. Python 2 was also PSF's interpreter. IBM handling a COBOL upgrade like PSF handling the 2-3 transition would be unacceptable.

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?

Re: Sunsetting Python 2

#549

Post by [deleted] »

sametmax wrote: post #544
gridlockd wrote: post #518

Earlier quoted context omitted.

The entire science stack is "terrible C extensions". This is also the kind of tight-budgeted stuff that needs relatively rare Python/C developers, not just your average overpaid Python web developer. I'm not saying we would've cured cancer if people didn't have to deal with this bullshit, but it's definitely a setback.

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…

[deleted]

Re: Sunsetting Python 2

#550

Post by WorldMaker »

BeetleB wrote: post #363
Kaiyou wrote: post #311

Earlier quoted context omitted.

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

>considering timelines in engineering are to support a version for 60 years. In the vast minority of cases. Not in most electrical engineering (except power plants), nor in computer engineering. 60 years ago was 1959. What software/computer project from that time is still running? Even moving outside of the electrical domain, how many physical products outside of civil engineering is expected to last that long. I cer…

If there's a difference it's not time scale necessarily, it's that CPAs are better at amortizing support/maintenance costs across decades. CPAs have amazingly detailed depreciation charts for non-software engineering lifecycles. If you build a civil engineering project, you figure out asset depreciation versus maintenance schedules, and you budget accordingly.

I've yet to see a CPA adequately depreciate software assets, anywhere. Maybe we should help them out by building better depreciation schedules. There seems to be a lot of CPAs that don't believe software depreciates over time, and maybe that's the largest disconnect in labeling it "tech debt", because accountants hear that term and think they can ignore it on a balance sheet they don't care about, but "tech depreciation" might actually scare them straight (until they find the tax advantages in calling it that).

Post reply on HN