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

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

[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.