Live data from Hacker News

Python 2.7 Retirement Countdown

pythonclock.org

31–40 of 81 posts

Re: Python 2.7 Retirement Countdown

#31

No, I'm getting sick of my code being broken. My C code from 15 years ago works fine, but code in other languages can end up breaking within a year. I've moved much of my development back to C++ just so I can have reasonable confidence my code will work when I come back to it in a couple of years. I don't care if Python 2.7 never gains another feature, as long as my code will still work in Windows 13 and Mac OS X 10.…

There's something to be said about "small" languages. Whenever Golang does a point release I update all my production code without a fear in the world, not because I have to, but because their may be a performance improvement here or there that I get for "free". I think I skipped 1.5 and 1.5.1 because of a slight regression when they switched to a go-based compiler/runtime but other then that yeah, awesome.

Conversely I'm always behind on Node as it's realllly annoying when a third-party lib breaks from an update. Larger packages will be fine but when you're dealing with say a Meteor package derived from an NPM package it's pretty shitty.

Re: Python 2.7 Retirement Countdown

#33

No, I'm getting sick of my code being broken. My C code from 15 years ago works fine, but code in other languages can end up breaking within a year. I've moved much of my development back to C++ just so I can have reasonable confidence my code will work when I come back to it in a couple of years. I don't care if Python 2.7 never gains another feature, as long as my code will still work in Windows 13 and Mac OS X 10.…

It's called "moving forward". The technology sector moves fast, and you need to keep up. Nothing is ever going to get better with that sedentary mindset.

Re: Python 2.7 Retirement Countdown

#34
post #29

Earlier quoted context omitted.

It's not that maintainers want to screw anyone over, it's that folks who give away labor for free to maintain libraries want to be able to use the new features in 3.x without spending additional unpaid labor to maintain separate 2.x versions.

And vice-versa, it is not like users have some grunt against developers. They just don't want to go through the pain of having to migrate their applications and the instability that this will bring. (Disclaimer: I am not supporting any side)

Why does end-of-life mean you have to migrate your application? 2.7 isn't going to just go poof and self-destruct on your computer.

Re: Python 2.7 Retirement Countdown

#35

No, I'm getting sick of my code being broken. My C code from 15 years ago works fine, but code in other languages can end up breaking within a year. I've moved much of my development back to C++ just so I can have reasonable confidence my code will work when I come back to it in a couple of years. I don't care if Python 2.7 never gains another feature, as long as my code will still work in Windows 13 and Mac OS X 10.…

It's called "moving forward". The technology sector moves fast, and you need to keep up. Nothing is ever going to get better with that sedentary mindset.

Well, if you ask me, backward compatibility should only be broken with extreme reluctance, because it's a huge waste of time to be rewriting things that already work. See also Angular 2.

Re: Python 2.7 Retirement Countdown

#36

This again? Python 2.7 is never going away, no matter how much people wish it did. Python is the Cobol/Java of dynamic languages. There is way too much volume of code written in it. This means there is a golden consulting opportunity for those willing to take it: support 2.7 code/libraries for money.

This again indeed, because Python 2.7 is going away. Python 3 is the future, and we've been resting on our "eh, python 2.7 is convenient enough" mindset for too long. We should just bite the bullet and move to 3, which isn't even that bad of a migration. Also, "supporting legacy code for money" is already everyone's job, unless you're implying that there are as many Python programmers as there are COBOL ones.

Python 2.7 is not going away and why do you care anyway? People like you and the author of this website should just fuck off. People like Python 2.7, just let them.

Re: Python 2.7 Retirement Countdown

#38

This again? Python 2.7 is never going away, no matter how much people wish it did. Python is the Cobol/Java of dynamic languages. There is way too much volume of code written in it. This means there is a golden consulting opportunity for those willing to take it: support 2.7 code/libraries for money.

This again indeed, because Python 2.7 is going away. Python 3 is the future, and we've been resting on our "eh, python 2.7 is convenient enough" mindset for too long. We should just bite the bullet and move to 3, which isn't even that bad of a migration. Also, "supporting legacy code for money" is already everyone's job, unless you're implying that there are as many Python programmers as there are COBOL ones.

That's incredibly naïve. Python 2 will be around and have new software written with it for at least a decade to come. Keep saying "Python 3 is the future", that will surely make companies invest in switching. Meanwhile ford still uses 40 year old IBM mainframes with COBOL, and will continue to do so until they are physically unable.

Re: Python 2.7 Retirement Countdown

#39

3 Years 10 Months 13 Days 20 Hours 54 Minutes 31 Seconds until a community fork occurs.

I don't think so. I know it's popular to hate on Python 3, but the community has not rejected Python 3, they've just taken a while to cozy up to it. The transition was always intended to be gradual (perhaps not this gradual, but still).

At this point, the chicken-and-egg problem has effectively been solved for Python 3. Practically every major Python library has Python 3 support these days. The mainstream Linux distros are switching to Py3 as the default this release cycle. The largest remaining holdout will probably be PyPy diehards, but 3 years is a long time and I'm confident that the community's increased interest in Py3 will be made manifest to the PyPy development team in the not-too-distant future.

I believe that the posted site is correct, Python 3's time is now. While there probably will be a fork specifically intended to provide security backports for legacy applications, I don't think it will see widespread use (the people who continue to run Py2 applications at that point will probably keep running the never-to-be-updated again CPython runtime).

Re: Python 2.7 Retirement Countdown

#40

Earlier quoted context omitted.

This again indeed, because Python 2.7 is going away. Python 3 is the future, and we've been resting on our "eh, python 2.7 is convenient enough" mindset for too long. We should just bite the bullet and move to 3, which isn't even that bad of a migration. Also, "supporting legacy code for money" is already everyone's job, unless you're implying that there are as many Python programmers as there are COBOL ones.

That's incredibly naïve. Python 2 will be around and have new software written with it for at least a decade to come. Keep saying "Python 3 is the future", that will surely make companies invest in switching. Meanwhile ford still uses 40 year old IBM mainframes with COBOL, and will continue to do so until they are physically unable.

You've just proved his point by comparing Python 2 with 40 year old mainframes. There will always be users of legacy software, but that doesn't stop it from being, well, legacy software.
Post reply on HN