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.

Comments

add `python2` and deprecate `python`

[Tora]

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

Re:add `python2` and deprecate `python`

[KiloByte]

/usr/bin/python is not going to ever point to python3 in Debian, at least according to the maintainer. Unfortunately, there are distros which have done this step.

Python 2 and Python 3 are similar but different languages, akin to Perl 5 and Perl 6. As they're not supposed to be compatible, changing the meaning of the hashbang is a recipe for disaster.

PEP 394: /usr/bin/python should not be python3

[caseih]

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.

Re:PEP 394: /usr/bin/python should not be python3

[Anonymous Coward]

But it is because people are afraid to leave it's relative safety.

By relative safety you mean breaking working, debugged code.
All of this work for moving to the latest and greatest thing that that causes you nothing but headaches and redoing work you did years ago.

Yeah I'll take relative safety over that nonsense.

Here is a hint, programming languages exist to write programs in, not to stroke the programming language designers' ego.

Re:PEP 394: /usr/bin/python should not be python3

[93 Escort Wagon]

If you've stubbornly refused to migrate your existing code for 9 years, then frankly, you're a fuckwit that deserves to have your code break.

No, it means that he's likely someone who gets paid to write code, and has to prioritize writing new tools / programs over going back and rewriting old stuff that is already perfectly functional.

Most employed coders don't have the luxury of picking and choosing what they're going to spend their time working on.

Re:PEP 394: /usr/bin/python should not be python3

[JanneM]

Apart from having to rewrite existing code, one issue is that in some fields (HPC and supercomputing) the facilities can be very conservative about what they install. In many places, they install whatever is the conservative, safe default when the system is built, then they never update it. If you do offer newer versions of something, you add it alongside the existing software, not replacing it. When the system us upgraded or replaced, you make very sure to add (or backport) the old versions for the new system.

A major reason is that research projects - that can go on for 5-10 years - don't want to switch software versions mid-stream. If you are comparing an analysis of your current data with data from five years ago, you want to be sure any differences is due to the data, not because you changed software versions somewhere along the line.

This means that many systems may not offer Python 3 at all; or if they do, they still point to Python 2.7 as "the" python, and they will until the system is decommissioned years and years from now. And that means a lot of scientific software still primarily (and sometimes only, though that's becoming rare) target Python 2, since that's where a lot of their users are.

Python 2 will in practice live on for at least another decade, and quite likely for longer than that. I do agree that new projects probably should seriously consider using Python 3, but Python 2 disappearing will not happen.

Re: PEP 394: /usr/bin/python should not be python3

[TheRaven64]

C++'s std::auto_ptr was deprecated in C++11 because it's almost impossible to use correctly and code using it is trivial to migrate to using unique_ptr - if it isn't, then that's usually an indication that there were subtle bugs in the original that now become compile failures. In spite of that, it's still there in C++11 and C++14 and wasn't removed until C++17. You can still compile code as C++14 and use it, it's just a terrible idea.

Re: PEP 394: /usr/bin/python should not be python

[AndroSyn]

What's the size of an int again ?

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.