Fedora 41 Finally Retires Python 2.7 (fedoraproject.org) 25
"After sixteen years since the introduction of Python 3, the Fedora project announces that Python 2.7, the last of the Python 2 series, will be retired," according to long-time Slashdot reader slack_justyb.
From the announcement on the Fedora changes page: The python2.7 package will be retired without replacement from Fedora Linux 41. There will be no Python 2 in Fedora 41+ other than PyPy. Packages requiring python2.7 on runtime or buildtime will have to deal with the retirement or be retired as well.
"This also comes with the announcement that GIMP 3 will be coming to Fedora 41 to remove any last Python 2 dependencies," adds slack_justyb. GIMP 2 was originally released on March 23, 2004. GIMP will be updated to GIMP 3 with Python 3 support. Python 2 dependencies of GIMP will be retired.
Python 2's end of life was originally 2015, but was extended to 2020. The Python maintainers close with this: The Python maintainers will no longer regularly backport security fixes to Python 2.7 in RHEL, due to the the end of maintenance of RHEL 7 and the retirement of the Python 2.7 application stream in RHEL 8. We provided this obsolete package for 5 years beyond its retirement date and will continue to provide it until Fedora 40 goes end of life. Enough has been enough.
From the announcement on the Fedora changes page: The python2.7 package will be retired without replacement from Fedora Linux 41. There will be no Python 2 in Fedora 41+ other than PyPy. Packages requiring python2.7 on runtime or buildtime will have to deal with the retirement or be retired as well.
"This also comes with the announcement that GIMP 3 will be coming to Fedora 41 to remove any last Python 2 dependencies," adds slack_justyb. GIMP 2 was originally released on March 23, 2004. GIMP will be updated to GIMP 3 with Python 3 support. Python 2 dependencies of GIMP will be retired.
Python 2's end of life was originally 2015, but was extended to 2020. The Python maintainers close with this: The Python maintainers will no longer regularly backport security fixes to Python 2.7 in RHEL, due to the the end of maintenance of RHEL 7 and the retirement of the Python 2.7 application stream in RHEL 8. We provided this obsolete package for 5 years beyond its retirement date and will continue to provide it until Fedora 40 goes end of life. Enough has been enough.
kinda (Score:2)
Old languages never die. Fedora supports imagej effigy had a 2.7 compatible jython
Re: kinda (Score:4, Interesting)
In my line of work, people are still writing software in fortran 77.
Cobol is still around, despite rumors of it having been displaced by java.
Java itself is almost as old as python.
Software engineering as a large industry is still barely two generations old. We're not there yet, but at some point soon we'll reach a saturation point where there will be a high barrier to justifying the creation of new languages, and we'll be stuck with 50 or 100 year old languages. Maybe the tools will be better, but the whole thing will be much more commoditized than it is now.
Re: (Score:3)
Why am I not surprised that our resident RightwingNutjob is stuck in the 1950s ;-)
Re: (Score:2)
So Python and Java were invented in the 50's? Who knew?! /s
Re: kinda (Score:2)
Python may as well have been invented in the 50s. How else can you make sense of the tab character having significance?
Re: (Score:2)
Python may as well have been invented in the 50s. How else can you make sense of the tab character having significance?
Python is whitespace dependent... just like FORTRAN and COBOL... so you're not that far off.
Re: (Score:2)
Question: Do you genuinely not know what Fortran is? You couldn't have possibly have read the 3rd line of the GP's post without reading the 1st.
Re: (Score:3)
Due to the millions of developers who have been suffering from it for so long, I contend that the Python3 release was the worst software disaster ever.
The way they transitioned to Python 3 was certainly boneheaded, but there were many larger software disasters.
One example would be the C++ design decision to continue to require that all declarations lexically precede their use in each and every source file. This has ended up requiring manual management of innumerable header files and their recursive dependencies. Once templates became popular, it also required recompiling much of the entire program repeatedly, once for every individual source file, so tha
Re: Python 3 was the worst software disaster ever (Score:2)
Requiring declarations to lexically precede is considered and important feature in Ada. These things tend to be favored or not depending on industry and application. It might be a hint as to why we see C++ and Ada in decades old aerospace systems and not Python.
Re: (Score:2)
You probably see headers like that in decades-old systems because low-powered computers of yore didn't have enough memory to scan for all the declarations used throughout the program and save them for the compile. So they saddled people with the work.
Re: (Score:2)
Ada compilers struggled to make it on the market because they are rather complicated and consumed a relatively large amount of memory on the host systems at the time. Even if the language grammar is relatively simple compared to C++. Sure, neither holds a candle to how much RAM a Python runtime requires. But I wouldn't put Ada in the same category as designed for simplicity such as Pascal and its contemporaries.
For the most part, organizing a non-programming document by section titles and table of contents
Re: (Score:2)
Or interface and implementation in Java.
Yes, the Java culture manages to go way overboard on interfaces in many cases. However, they do this *without* requiring declarations to appear in lexical order above where they are referenced (the compiler will sort it all out and tell you if you have an interface problem, regardless of the order of program lines), nor to they kludge putting things above other things by using #include directives. That C/C++ phenomenon is specifically what I was talking about.
Re: (Score:2)
Re: (Score:2)
Yep.
The fact that they knew they were breaking it but didn't think to require a comment like "#Python3.0" at the start of a program so the system could figure it out is unforgivable.
Re: (Score:2)
Well, on Linux (and I assume Unix) based systems you COULD include a comment at the head of the file to tell the system which compiler/interpreter to use. But this was only used if you made the file executable...and executed it by filename.
(I'd be more specific, but I never use that approach, so I've forgotten the terminology. Just a second while I look it up...)
The first line of all your Python programs should be a shebang line, which tells your computer that you want Python to execute this program. The
Re: (Score:1)
> require a comment like "#Python3.0"
You mean like this?
#!/usr/bin/python3
I never got all the hate Python got with the transition. They talked about it for about a decade before doing it and supported the legacy version for over a decade. They provided tools and transitional versions, which Python 2.7 was.
Re: (Score:3)
Python2 strings could not be compatible with unicode. (Or was that "could not, with reasonable efficiency, be compatible".)
If you want a disaster, look at how Perl handled the transition.
Re:Python 3 was the worst software disaster ever (Score:5, Insightful)
The disaster is how the distributions handled the transition in both cases.
It's extra work no question, but the correct thing to do was to continue to include the older version, and use the new version for new projects.
It's still necessary to have Python 2.7 around sometimes, for doing things with old projects.
Re: (Score:1)
*Proposed* changes (Score:4, Informative)
Red Hat's "python maintainers" shouldn't complain (Score:2)
Well, this is what they draw a salary for. After all, when Red Hat closed its source off from non subscribers, they justified it by saying they were providing all this extra work to maintain the code. Maintaining a python 2 version to CentOS 7's EOL runs part and parcel with that.
People don't get to pick and choose to do only the fun parts of their jobs.
Has Gimp 3 been released? (Score:3)
Re: (Score:3)
Based on what it says on gimp.org, Gimp 3 doesn't seem to have been released. In fact, it missed its predicted release date in June [gnome.org]. It doesn't look like there has been an RC release and the latest development snapshot says that it "might be one of the most unstable releases in the 2.99 series" [gimp.org].
Given the limited developer resources, the GIMP team has been extremely reluctant to place hard dates on the GIMP 3.0 release schedule (it will ship when it believed to be ready). The first GIMP 3.0 Release Candidate was recently given a newly revised target date of end of July, although as the RC date has slipped previously, it may very well slip again. Until feedback is received from the RC's it is hard to know how long it will take for a formal 3.0 release. Last I looked there were about a dozen block