Great stuff. But what about alternative python interpreters that have been lagging behind? Jython is 2.7.1 and IronPython is 2.7.9
Sunsetting Python 2
31–40 of 733 posts
Re: Sunsetting Python 2
#32Earlier quoted context omitted.
I honestly don't believe that many will step up and take over. Many will complain, but few will do the actual work. Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.
RHEL 7 depends on python 2.7 and will have security/maintenance support till June 2024. So for security updates, I guess we can just track RHEL7/CentOS7 python 2.7.
Correct
Also the longer a software is around, the lower the chance of some showstopper showing up (not 0% chance though)
What's most likely is that one important library in 2.7 stops talking to some upgraded system version (think OpenSSL for example) then what depends on it stops working.
Re: Sunsetting Python 2
#33> If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team i…
They say volunteers, so I think they mean just people working for free. In the next section they mention you can probably find support from your vendors or pay a third party to fix it. It then ends with the sentence
> If you need free help from volunteers, look at this help page.
Which links to the help page to learn python, haha. I think the point is that you can fork it or pay someone to fork it, but you won't find anyone else willing to fix your problems for free.
Re: Sunsetting Python 2
#34One missing question: Q) I like Python 2. Can I take over Python 2 maintenence? A) NO. Try it and we'll sue you.
Is that the stance? I haven't heard anything on that front.
I'm sure there is a great market opportunity for some developers to do the migrations, or to alternative do backporting for some large companies not interested in mingrating.
Re: Sunsetting Python 2
#35Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a long time. Since the stuff is open source, wouldn't it be nicer if it was possible to fix a bug if needed? Not saying that it should be actively worked on. But maybe one person could be appointed to look over bug fix pull requests (which shouldn't be that frequent these days).
Just don’t let your technical debt fossilize. At the beginning seems like a good idea to invest little money in supporting legacy rather than migrating it, but for example, supporting and maintaining COBOL applications is a huge headache. Companies even pay big bucks for formation of new professionals and integrate the old solutions with modern applications is not even that easy since some of the OS are even alien to TCP/IP interfaces let alone modern programming interfaces (and there is nothing worse than an HTML interface on top of the old non ANSI terminal interface, even if you knew where the F21 used to be)
Re: Sunsetting Python 2
#36Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a long time. Since the stuff is open source, wouldn't it be nicer if it was possible to fix a bug if needed? Not saying that it should be actively worked on. But maybe one person could be appointed to look over bug fix pull requests (which shouldn't be that frequent these days).
COBOL has an upgraded version? Besides, legacy is not a perfect excuse for using python 2 since it's so similar to 3 and with some amount of effort you could port it over quite easily.
Re: Sunsetting Python 2
#37Earlier quoted context omitted.
> Shared hosting providers Like Google App Engine lol. GAE Standard Environment doesn't support Python 3.
This is incorrect. https://cloud.google.com/appengine/docs/standard/python3/
You're technically correct in that GAE standard offers python 3, but it's not the same as their python 2 offering.
Python 2 is part of the first generation runtimes, python 3 is part of the second generation runtimes. They are not out of the box compatible, even if your python code works on 2 and 3. The first generation runtime included many APIs that are simply just not available in the second gen (you need to build them yourself). See link for more info.
Re: Sunsetting Python 2
#38Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a long time. Since the stuff is open source, wouldn't it be nicer if it was possible to fix a bug if needed? Not saying that it should be actively worked on. But maybe one person could be appointed to look over bug fix pull requests (which shouldn't be that frequent these days).
As someone who works on a 99% Python 2 codebase I think this is a very necessary step. Hopefully one of our larger customers will realise we are still running their critical infrastructure on Python 2 and make enough of a fuss that we can justify the expense.
Re: Sunsetting Python 2
#39One missing question: Q) I like Python 2. Can I take over Python 2 maintenence? A) NO. Try it and we'll sue you.
Why would anyone like python2 so much better than python3 that they would want to fork it into its own language? The two languages are already incredibly similar and python3 has a much larger active community.
Re: Sunsetting Python 2
#40One missing question: Q) I like Python 2. Can I take over Python 2 maintenence? A) NO. Try it and we'll sue you.
Is that the stance? I haven't heard anything on that front. I'm sure there is a great market opportunity for some developers to do the migrations, or to alternative do backporting for some large companies not interested in mingrating.
I don't see how they could sure given that Python is open source. Maybe they own the Python trademark and you'd have to call it something else?