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

[Njorthbiatr]

I do all my work inside of a virtual environment anyway.

But I'm sick of python2 being around as long as it has. It needs to die and not be used anymore by anyone. But it is because people are afraid to leave it's relative safety.

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

[truedfx]

Fedora:

This change is about what happens once PEP 394 is updated (and we will drive that update if needed):

PEP 394:

Future Changes to this Recommendation It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2.

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

[Dutch Gun]

How do they deal with the end-of-life of Python 2.7 in 2020 then? Isn't leaving an unsupported interpreter shipping as the "default" python a bad idea?

Anyhow, it just goes to show you the staying power of legacy systems. Once something is in place and working, it takes a lot of time and effort to get things upgraded. People understandably don't want to have to rewrite perfectly working code just because someone decides to make improvements and break compatibility. I suspect Guido vastly underestimated the detrimental effect splitting the language into incompatible versions would have, and the headaches it would still be causing nearly a decade later.

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

[Anonymous Coward]

But I'm sick of python2 being around as long as it has. It needs to die...

Really? Python 2 is simple and elegant. Python 3 is not.

Examples:
* Python 2 has polymorphic division: 5 / 2 = 2 and 5.0 / 2 = 2.5. In Python 3, you need to use two different division operators: // for integer division on / for float. If you want to support both integer and floating point division in your function, you can't do it python 3 (but you can in python 2 (polymorphic div)). This retarded design (// and / in py3) was done thanks to numpy developers.

* Python 2 has simple ASCII strings and unicode strings as two different types. Python 3 merges them into one (utf-8). This causes a lot of difficulty to newbies and experienced developers who just want to use ascii without the complexities of unicode.

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

[Billly Gates]

Virtual machines.

Shoot my last job we supported several client environments. 2 out of 7 we had USED IE 6 as late as early 2017 we used IE 6 ... with one running in quirks IE 5.5/Netscape 4.7 mode for their mission critical apps!

You would think they would upgrade? I asked one of their project managers and mentioned I used a script debugger and saw copyright 1999 all over the place. She laughed and said yep that sounds about right. It is too important to leave. We have millions upon millions of .HTA and VBScript which holds it together.

Thanksfully they were smart to DMZ the hell in a private locked down VLAN and run it off of a Citrix WIndows 2000 VM and it can't leave that intranet.

Same is true with COBOL and legacy java and XP apps. Python 2 will be moved to an old legacy VM in citrix or VMWare locked down tight to just do it;s job running obsolete code. Shoot IBM 360 mainframe COBOL is still run in an emulator inside another emulator in a VM on modern IBM mainframes for banks and airlines as you all read this. JPMorgan lost the source code sometime in the 1970's and it is too import to ever upgrade.

Research technical debt?

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:Why stop there?

[Billly Gates]

Why not just eliminate Python completely and free us all from it's terrible reign? ;)

Agreed. Since node.js is cool now with the hipsters lets all vote for it! After all the PHb's Looove standards and less things to support is always better.

Re:python is a trainwreck

[LostMyBeaver]

I believe if you recall correctly, they weren't completely incompatible.

1) Mac OS 8.x and later began forcing developer to the Carbon API... which was certainly better than doing things like waiting or hardware timers and injecting values into kernel space to change window titles.
2) Mac OS X shipped with the Carbon API which means that if a developer put most of his/her effort into porting their apps to Carbon, it should have just been a recompile.
3) Mac OS X shipped with Classic mode compatibility which had about a 98% success rate in running earlier Mac software... from OS 9 and Apple even maintained and updated OS 9 for a few versions to support newer Carbon APIs for the hold outs.
4) Every time Apple sneezed all software had to be recompiled for Mac. I'm not sure if you remember, but Adobe made their fortune selling upgrades with every version of Mac OS because going from Mac OS 5.0.1 to Mac OS 5.1 would move memory locations and all software would need to be updated and Adobe charged for that.

BTW I was coding on Mac OS X back when it was called Yellow Box and shipped with the Mac Classic desktop. For nearly a year, I worked on an operating system which in every possible way was in fact Mac OS 10. The only thing that made Mac OS X less of a Mac OS was that it actually did work with earlier software most of the time.

Re:python is a trainwreck

[Junta]

Python has long had the problem of trying to provide the 'right' answer and anytime they decided they at one point had the 'wrong' answer, they change minds and break compatibility, for the sake of the newcomers to the current language.

On the one hand, it means python doesn't have to contend with problems other languages have of needing to support old syntaxes and mechanisms that are pretty ugly (Javascript has accumulated tons of different ways of supporting object oriented design).

On the other mind, it is frustrating as hell to provide python software to third parties to use with their interpreter of choice. Even when you go through all sorts of hell to make sure it works on python 2.6, 2,7, 3.3, 3.4, 3.5, and 3.6, some python zealot will still bitch about 'oh, you shouldn't be supporting 2 at all, especially not 2.6', not caring that you have tons of users still using 2.6 that you'd rather not tell to fuck off.

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.