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

561–570 of 733 posts

Re: Sunsetting Python 2

#561

Post by mgkimsal »

mindcrime wrote: post #539
gridlockd wrote: post #525

Earlier quoted context omitted.

You're missing the point. If decision makers saw it coming that Python will just break in two, they would have never allowed its use. Other "serious" programming languages rarely if ever break, and when they do, it's usually minor. Python2 will almost certainly still remain in widespread use and it will still get security updates through alternative distribution channels. It's not that much work fixing such relativel…

It's not "broken"... Python3 is just the evolution of the language. Languages change and evolve, some more and some less than others. Sure, Java or COBOL maybe have done a better job of not breaking backwards compatibility, but Python 3 isn't exactly Perl 6 here. But hey, if some 3rd party group effectively forks the language and maintains a Python2 branch after the official EOL date, good on them. But I'd argue that…

IceWeasel FTW.

Security through obscurity, baby...

Re: Sunsetting Python 2

#562

Post by GeorgeTirebiter »

sametmax wrote: post #505
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...

Ordered dicts and f-strings are also very sweet!

And optional type specifiers. This was the key for me.

Re: Sunsetting Python 2

#563

Post by simcop2387 »

bigiain wrote: post #248
Animats wrote: post #7

Some shared hosting providers are still offering Python 2.6 as their main offering.[1] Optionally, there's Python 3.2, probably the worst 3.x version. [1] https://www.hostgator.com/help/article/what-software-and-pro...

I bet there is still some shitty hosting company somewhere offering Perl4 CGI script hosting. Doesn't mean we should do anything except laugh at their incompetence (or perhaps be impressed by their ability to monetise other people's incompetence...)

No idea about CGI hosting, but I do allow perl 4 (and 3 and 2 and 1) scripts to run on my pastebin, https://perl.bot/ . In this case it's not incompetence but insanity.

Re: Sunsetting Python 2

#564

Post by gwbas1c »

ilikehurdles wrote: post #558
gwbas1c wrote: post #407

Earlier quoted context omitted.

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.

I might be misunderstanding your comment, but I have encountered source code that is not forward compatible in java. Some examples below... Incompatibilities between JDK 7 and JDK 6: https://www.oracle.com/technetwork/java/javase/compatibility... Incompatibilities between JDK 8 and JDK 7: https://www.oracle.com/technetwork/java/javase/8-compatibili... An exerpt from the Compatibility Guide for JDK 8 [1]: >In general,…

Thanks for proving my point.

The incompatible areas that you explain amount to bug fixes and obscure areas of the language. They aren't anything like Python 2 vs 3.

Re: Sunsetting Python 2

#565

Post by raspie »

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

I think it's less about the difficulty of manual changes and more about the cost to verify that all of the changes actually work.

Dynamic typing on the language side, and a less than perfect test suite on the user side are not a good combination for large projects facing a project wide migration.

Re: Sunsetting Python 2

#566

Post by ilikehurdles »

gwbas1c wrote: post #564
ilikehurdles wrote: post #558

Earlier quoted context omitted.

I might be misunderstanding your comment, but I have encountered source code that is not forward compatible in java. Some examples below... Incompatibilities between JDK 7 and JDK 6: https://www.oracle.com/technetwork/java/javase/compatibility... Incompatibilities between JDK 8 and JDK 7: https://www.oracle.com/technetwork/java/javase/8-compatibili... An exerpt from the Compatibility Guide for JDK 8 [1]: >In general,…

Thanks for proving my point. The incompatible areas that you explain amount to bug fixes and obscure areas of the language. They aren't anything like Python 2 vs 3.

After seeing the months- to years-long process that enterprises have undertaken when migrating from one JDK version to another because of these "obscure areas", I have little empathy for anyone delaying a python upgrade they've been given a 10+ year window for. Ruby 1.8 to 1.9 was similarly painful to python.

Re: Sunsetting Python 2

#567

Post by musicale »

This would never have been such an unpleasant issue if Python 3 hadn't broken backward compatibility in very annoying ways; one of the more inexcusable examples was removing the print statement, a convenient piece of syntax that dates to antiquity, and which could have peacefully coexisted with the print() function in Python 3.

Now that Python no longer has a BDFL, maybe we'll get the print statement back? ;-p

Re: Sunsetting Python 2

#568

Post by BeetleB »

WorldMaker wrote: post #550
BeetleB wrote: post #363

Earlier quoted context omitted.

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

They really need our help :-)

In a previous job that was mostly in an engineering/manufacturing department, but with a lot of Perl/Python automation scripts, we had an internal conference. One of the keynote talks was when not to automate using SW. It went into the cost of maintaining SW over the long term - including the fact that authors leave, and people who understand their scripts require higher salaries. Most people who write these scripts are not hired for SW roles, so their replacements likely cannot debug/extend.

Re: Sunsetting Python 2

#569

Post by ensignavenger »

pfranz wrote: post #502
ensignavenger wrote: post #180

Earlier quoted context omitted.

But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. You also could have contributed to your dependancies to help them become Python 3 compatible.

I often hear this, but I just don't see this working in practice. A very similar example I have experience with, I've often worked with people who tried to write code that would be "compatible with Windows" (I primary work in a Linux environment). It makes the code more difficult to read and as soon as you try and run it in Windows it fails spectacularly. You can write code that's compatible with both Python 2 and 3,…

There are a ton of open source projects that have done python 2/3 simultaneously in practice.

I get your point though about not being able to run full integration tests due to dependencies. Still, if you were making a good effort to keep the code Python 3 compliant, it would make upgrading much easier.

Also, my other suggestion- contributing to Python 3 compatibility for modules you depend on! That will give you Python 3 experience :)

Re: Sunsetting Python 2

#570

Post by bigiain »

simcop2387 wrote: post #563
bigiain wrote: post #248

Earlier quoted context omitted.

I bet there is still some shitty hosting company somewhere offering Perl4 CGI script hosting. Doesn't mean we should do anything except laugh at their incompetence (or perhaps be impressed by their ability to monetise other people's incompetence...)

No idea about CGI hosting, but I do allow perl 4 (and 3 and 2 and 1) scripts to run on my pastebin, https://perl.bot/ . In this case it's not incompetence but insanity.

Nice!

Much respect. That’s retro-cool.

Post reply on HN