It Will Take Fedora More Releases To Switch Off Python 2 (phoronix.com)
An anonymous reader quotes Phoronix:
Finalizing Fedora's switch from Python 2 to Python 3 by default is still going to take several more Fedora release cycles and should be done by the 2020 date when Python 2 will be killed off upstream. While much of Fedora's Python code is now compatible with Py3, the /usr/bin/python still points to Python 2, various python-* packages still mean Python 2... The end game is to eventually get rid of Python 2 from Fedora but that is even further out.
Fedora is now gathering feedback on a Wiki page explaining the switch.
Fedora is now gathering feedback on a Wiki page explaining the switch.
It is really a bad look and proves they are not packing a python
Switching `python3` to `python` is just inane at this point. Get rid of `python` in general and explicitly call what you need, the problem will resolve itself over time, and there will not be a problem with python4 following in suit. Either that or go the java route (which is also a nightmare to manage).
--
tora
tora
Python developers themselves have stated in PEP 394 that /usr/bin/python should *not* be linked to python3. Instead scripts should just use #!env python3 explicitly in the shebang to requestion python 3.x Or python4, or python5, as those generations are some day released.
I think it's Arch linux that changed /usr/bin/python to point to python3, but this is not recommended by any Python developer and horribly breaks things unnecessarily and is incompatible with all other distros. Besides if /usr/bin/python pointed to python3, and if python4 comes along, we'd have to go through all this rubbish again. Explicit in this case is better than implicit.
There is no good excuse for this sort of obsolescence. Fedora has the ability to both one time and dynamically recompile as well as emulate. They and any OS manufacturer can fix this problem. It is time for regulations that enforce a rule that OS companies stop creating obsolescence but must instead maintain legacy support.
Python is a complete trainwreck. So much crap still relies on Python 2 and them some needs Python 3. I mean they might as well be completely different languages. Why didn't they just give Python 3 a different name entirely?
This is almost as bad as the disaster known as Perl 6.
Editordavid
Thanks for refreshing my limited faith in the /. werld..
Finally Some news for nerds..!!!!!
Thank you
So there we have it. The Python developers themselves make this a total non-issue in a sensible way.
Now that this Python "problem" is out of the way, perhaps it's time for the Fedora maintainers to focus on the real problems plaguing their distro.
The first problem is systemd, obviously. The solution to this Windowsification of Linux is clear: get rid of it, and use OpenRC instead. Problem solved.
The second problem is GNOME 3. It can't be salvaged at this point. Like systemd, it should be thrown out. It could be replaced with MATE, which is based on the much more usable GNOME 2. Problem solved.
The third problem is RPM. It's an antiquated package format. They should use APT instead. Then DNF can be discarded in favor of the APT tools. Problem solved.
And not python. It broke compatibility and there are a ton of projects that have little use for the new major version.
you script a prototype.
you compile a program for distibution.
It needs major/minor versioning.
Seems like far too many people forget, but python has *NEVER* been stable between minor releases in the same major number. That in fact is the whole reason why we have been on Python 2.7 for so long, it was the first 2 release that didn't break language constructs/abis/expectations in the 2 series, and the patchlevel releases more or less ended up only being bugfixes, resulting in code against the 2.7 releases being mostly reliable and compatible on any other release. In contrast many things broke between 2.4 and 2.5, 2.5 and 2.6, and variations between those. Someone a few years back was complaining exactly about this, and how they had code developed for 2.5 or something and the client worked on 2.4 and the server on 2.6, but neither ended up working on 2.5 because certain assumptions in the language parser changed from version to version and thanks to a lack of pedanticism in their code, different assumptions were made by different interpreters/modules that broke each in subtle ways.
Python needs all releases major and minor versioned, and if scripts are supposed to be truly 'generic' then there should perhaps be a 'python-generic' or 'python-majorversion' symlink if the application regression tests successfully against all of a specific major-version of python's minor versions.
Why not just eliminate Python completely and free us all from it's terrible reign? ;)
Anons need not reply. Questions end with a question mark.
More Linux fail. I love it.
Lots of crusty legacy and fanatical users mixed with users with a if it aint broke don't fix it attitude.
It will be around for a long time.
Maybe including both?
http://saveie6.com/
If you're an MBA at an auto manufacturer, you probably want people to trade in their cars after a year or two, rather than keeping them for 9 or 10 years. If you're an MBA at Apple, you want people to throw away their $1,000plus iToy every year or two, rather than keeping it for several years. Same thing here. Language writers love writing new languages, but can't be bothered with maintenance and fixing bugs.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
get these toy languages out of here
Warnings do not cause your compile to fail unless you use -Werror, in which case you explicitly asked the compiler to fail rather than just warn you about things like that.
Aren't you overheating yourself just a little here?
You wrote code in the language Python 2. It will still run with Python 2. Without rewrite. Forever (as long as a distro supports it or you can compile it yourself).
However, it will not evolve, and probably cease getting updates in itself and 3rd party libraries.
If, however, you want to use an evolving language for your next project, you may want to consider the language Python 3. Or any other language, which will probably have a steeper learning curve if Python 2 is your main proficiency.
If you don't like it, don't use it.
If you get paid to use it, be happy.
Here is a hint, programming languages exist to write programs in, not to stroke the programming language designers' ego.
The creator of python begs to differ.
"because C was designed properly from the start."
What's the size of an int again ?
Are you saying Indiana Jones, Johnny Depp and Perry the Platypus aren't men?
-- Make America hate again!
Google's little recruitment test is still explicitly python 2.
XML is like violence. If it doesn't solve the problem, use more.
and old perl still lives on. long live perl
This has always been an issue with Python, and the one reason I haven't really wanted to learn it.
sizeof(int);
The base types in C are implementation/platform defined. That is considered a feature as it allows decisions to be made that make the most sense for the platform. In general this means the int type is going to be the fastest type.
In modern C practices though there are the u_intXX_t types that allow you to select a specific size integer, should you need that.
The real flaw with C is the whole preprocessor mess. If you were going to attack C about something, that is what you aim at.