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

401–410 of 733 posts

Re: Sunsetting Python 2

#401

Post by skywhopper »

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…

As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users.

Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that you now need to change out all your hand tools, manufacturing lines, assembly robots, and equipment from multiple vendors from phillips to torx all at once. Sure, you can do some prep work, but you've got to coordinate a cutover at some point, in sync with tools that you have no control over or have to recreate from scratch. All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.

Re: Sunsetting Python 2

#402

Post by [deleted] »

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…

[deleted]

Re: Sunsetting Python 2

#403

Post by skywhopper »

normalhuman wrote: post #235
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…

> For my personal use case at least, this timeline worked out well for me. Hint for Hacker News commenters: 99% of the time, if your phrase includes the term "use case", you can safely just delete it and lose no meaning. It's just a way to say "for me" or "for them" that sounds more technical but really isn't. In this case, you could say "This timeline worked out well for me".

Hint for Hacker News commenters: 100% of the time, if your comment includes grammar or style advice, you can safely delete it and the discussion will lose no value. It's just a way to say "I'm smart" or "look at me" that sounds helpful but really isn't.

In this case, you could have said nothing.

Re: Sunsetting Python 2

#404

Post by djsumdog »

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

You have a dependency rot problem. Are you missing unit tests? Because having a ton of unit tests can reduce dependency rot, breakage and overall make engineering upgrades just a lot easier to deal with. They don't catch everything of course, but they can catch a lot.

If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities.

It's not just about Py2/3. Dependency rot is one of the worst form of technical debt. It often shows broken CI, broken security scanning, lots of generally broken processes that will just keep hurting a team further and further down the line.

Re: Sunsetting Python 2

#405

Post by chrshawkes »

koreth1 wrote: post #282
ueiuestu wrote: post #260

Earlier quoted context omitted.

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 would have said Java, but then they decided to shove modules down everyone's throat.

I would say the Perl but then the Perl 6 fiasco made Python 3 look like a model citizen for upgrading code.

Re: Sunsetting Python 2

#406

Post by joshuamorton »

Kaiyou wrote: post #365
fwip wrote: post #324

Earlier quoted context omitted.

You can keep running Python 2 just like you keep your COBOL systems running, nobody's gonna stop you except common sense.

Right, but in engineering it's kind of expected to get support for a version for at least 60 years. Software engineering is just really weird in that it moves so fast and nobody seems to care to break things.

What free things are supported for 60 years in engineering applications?

Name one.

Re: Sunsetting Python 2

#407

Post by gwbas1c »

Lt_Riza_Hawkeye wrote: post #370
coliveira wrote: post #359

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

>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 This is the same with Python. Python 2 code will continue to work with python 2 interpreters, just as java 1 code will continue to work with java 1 JVMs and JDKs. But neither are being actively develope…

No

Typically version N+1 of a language compiles version N, N-1, all the way back to version 1. Usually, when this isn't the case, the incompatible areas of a language were either marked experimental, or obscure use cases that very few people use.

Today's Java compiler will compile source code written for Java 1.

The issue with Python 2 and Python 3 is extremely unusual in a language.

Re: Sunsetting Python 2

#408

Post by djsumdog »

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…

Classic cars can still get parts after 25 years, but a lot of times its custom machine shop stuff. There is a market for it. Really there's also a market for restoring old computers (look at The 8-Bit Guy, LGR, The Living Computer Museum (Seattle) and all those other people who restore old hardware for fun and education.

But I get your point, those are special cases for preservation. For mainline things, especially with today's processes for continual integration, dependency checking and advance build tooling, dependency rot is something that should be accounted for in all software project plannings. If your dependencies are a few months out of date and you don't have the time to update them and re-run tests (people write tests right?) things are just going to hurt more and more later.

Re: Sunsetting Python 2

#409

Post by ZWoz »

Kaiyou wrote: post #365
fwip wrote: post #324

Earlier quoted context omitted.

You can keep running Python 2 just like you keep your COBOL systems running, nobody's gonna stop you except common sense.

Right, but in engineering it's kind of expected to get support for a version for at least 60 years. Software engineering is just really weird in that it moves so fast and nobody seems to care to break things.

They (in engineering general) aren't expected support something free though. Putting it another way: You can get you support with Python2, if you pay.

Re: Sunsetting Python 2

#410

Post by partialrecall »

dangxiaopin wrote: post #391
AlphaSite wrote: post #385

Earlier quoted context omitted.

I mean, arguably they’ve been telling you too move for far longer. So it seems reasonable to sunset it after 10 years.

So migrate a large production codebase to unstable API? With dependencies not yet migrated?

Loads of open source and commercial projects have already made the switch to python 3 years ago. If all of them could do it, so could your org. No excuses, you've made your bed, etc.
Post reply on HN