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.

Re:add `python2` and deprecate `python`

[petermgreen]

Note that is only one of the co-maintainers and he didn't say it would never happen only he didn't think it should ever happen.

Re:add `python2` and deprecate `python`

[KiloByte]

Except that Python's upstream concurs.

Re:add `python2` and deprecate `python`

[SumDog]

I thought even in the official Python documentation, you should never make /usr/bin/python -> python3? python3 should always be called explicitly.

Re:add `python2` and deprecate `python`

[fahrbot-bot]

Python 2 and Python 3 are similar but different languages, ...

Or, using the Python 3 comparison operator: Python2 ~==~ Python3

Sorry, forgot to also mention the corresponding "different, but similar" operator: ~=!=~

Re:add `python2` and deprecate `python`

[Kjella]

Sorry, forgot to also mention the corresponding "different, but similar" operator: ~=!=~

Oh god I know who built this "same same but different" language, it's the guys selling Rollex watches on the beach. Explains a lot...

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

[Rockoon]

or people just dont see a good reason to rewrite the code for a language that now has a proven track record of very significantly breaking compatibility.

New python programmers may not get it, but the programmers that poured their efforts into python code bases only to have the developers of python give them the middle finger... yeah... they got it.. they got the message

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

[Anonymous Coward]

All of this work for moving to the latest and greatest thing

That "latest greatest thing" is _9 years old_

9 years.
Next year it'll be a decade.

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. But even morons like you still have another 2 years to finally change that one function that won't work.

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

[Doogie5526]

Haven't thought this out very far, but you could just not install /usr/bin/python by default. If you need python2, you get "command not found" instead of something that /might/ work at first, but error pretty quickly. I think modern Fedora even recommends the package to install. Then, you just install the python2 package and /usr/bin/python works for your Python2 scripts.

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

[caseih]

Well odds are if a script has #!/usr/bin/python in it, it's a Python 2 script. If it's got #!/usr/bin/python3, it's a Python 3 script. I see no problem with this, even after Python 2 is retired. If Python 2 is retired and not installed, then running a python 2 script (with the default python link) will just result in an error. I think this is way safer than changing the default python link and having legacy scripts break mysteriously for the uninitiated. I don't believe PEP 294 will ever be changed, because it just doesn't need to be.

Why change /usr/bin/python when python 4 will come along? Maybe python needs to have some kind of simple version flag in the shebang line.

Personally I think Guido is actually quite amazed that Python has amassed the popularity that the python3/python2 split is even an issue!

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

[Anonymous Coward]

This causes a lot of difficulty to newbies and experienced developers who just want to use ascii without the complexities of unicode.

How DARE YOU want to use only US-ASCII. You 'murican cis-gendered white microaggressing asshole! Don't you know your users might be writing in Emoji!

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

[Dutch Gun]

Maybe python needs to have some kind of simple version flag in the shebang line.

Well, at that point, it's not much different than explicitly specifying your Python version, right? Ultimately, I think that's the correct answer going forward. Also, one would hope Python doesn't actually have to break backwards compatibility with each new major release going forward. Upgrading the Python interpreter is only a big deal because of the incompatibility between 2 and 3.

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

[sjames]

C++ having the fail doesn't invalidate the point at all, it just shows something else just as bad.,

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

[Dutch Gun]

Ah... well, when I said "they" I was talking more about distros, but your point about people using Python 2.7 legacy apps is well taken. They'll just take a snapshot and use it in a VM until the end of time, like a lot of other legacy stuff. Like I mentioned, legacy code has an unbelievable amount of traction, for good reason. The code was written once, at great expense, and currently works. It's hard to make a business case that a massive amount of work needs to be thrown at something for zero new functionality except "now it's version 3 compatible instead of version 2." So it doesn't happen.

So... Python 2.7 is the IE6 of languages, then? Or the new VB6?

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

[gl4ss]

: // for integer division on / for float.

dafueq who thought of this is a good idea? I guess it's more "clear" in that you don't have to look up what your variable types are or whatever, but it sure sounds like madness.

never really understood most of the appeal of python really, except if you want to avoid curly braces for some reason, but gah, that's just awful and would explain why people are using python2..

never was a fan of languages that break backwards compatibility for no good reason either - I mean, okay, I can understand it if you have two separate branches from the same ancestor language, but if your language is literally python2 and python3.. like, come on.

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 python3

[TheRaven64]

dafueq who thought of this is a good idea?

There's a growing movement towards preventing implicit casts in programming languages, because they're a common source of bug. The sane fix for this issue in Python would be to require that the / operand has the same types on both sides.

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

[Bongo]

VMs are to me a magical technology. At some point someone realised that working code was too important to allow to talk to something as base as hardware.

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

[Junta]

While somewhat frustrated that it breaks existing code, it also makes it needlessly difficult to write code that works on both for asinine reasons.

For example, if python 3 recognized 'xrange' word, then you could use xrange in both 2 and 3. But noooo, that wouldn't look pretty.

Same for other 'mistakes' they made, like naming their standard libraries things they didn't like later. They *could* have stubs with the old names in python3, but nooo...

There is an example of them doing the sane thing, at first they refused to recognize u'', now they do in python 3. So I can use b'' and u'' in python code and at least that chunk will be consistent from 2 to 3. I'm quite content to use b'' all over the place, and bytes() and bytearrays(), since it works in both 2 and 3 world.

Changing the meaning of unqualified strings I can understand. Changing the syntax of except so you must use 'as' to capture to a variable I can understand. Basically changes that can be made that work in both, so people delivering code that must work in RHEL6, for example, can port to python3 without it being a clusterfuck for the python 2.6 in RHEL6.

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

[Sepulep]

All of this work for moving to the latest and greatest thing

That "latest greatest thing" is _9 years old_

9 years. Next year it'll be a decade.

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. But even morons like you still have another 2 years to finally change that one function that won't work.

well apparently, it means that for _9 years_ no compelling reason to switch to python 3 has come up...for the 2 to 3 switch, there are no carrots..only a stick..tells you something..

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

[Billly Gates]

Well you recommend sticking with IE 6 when this clients call center agents need to go on the live internet to fedex.com and UPS.com to check package tracking? :-)

I think they dropped IE 6 support some 4 years ago.

It is not about hiding hardware in a level of abstraction. It is you need a modern secure environment and an ancient unsupported one working together and have requirements for HIPAA to keep data secure. You can't do that with XP even if we did hack it to run on modern hardware it has no patches so it would fail audit. Like I said IMB 360 mainframe software 40 to 50 years old is still run on banks, insurance companies, and airlines. This can't be run on a modern mainframe without emulation and virtualization PERIOD.

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

[TheRaven64]

Integer division is pretty common in C programs, where you want to use it for indexing and want the rounding behaviour, or where you're running in embedded systems without an FPU (or in kernel mode without an FPU context).

Python 3 should be called python3

[Anonymous Coward]

And not python. It broke compatibility and there are a ton of projects that have little use for the new major version.

Re:python is a trainwreck

[Rockoon]

Why didn't they just give Python 3 a different name entirely?

...because they werent trying to do the right thing... they were trying to do the "best" thing

Re:python is a trainwreck

[Luthair]

The best thing was to fuck over everyone else and piggyback on the name of an existing incompatible project?

Why stop there?

[Gravis Zero]

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

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

[murdocj]

I think you mean "this is almost as bad as the disaster know as Perl"

python2 == this decade's XP

[Billly Gates]

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?

Fuck planned obsolecence!

[knorthern knight]

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.

Re:Fuck planned obsolecence!

[Bongo]

For me it is fridges. I'm told they won't last ten years. My expensive German fridge was failing at 8. I mean, the plastics were just cracking all on their own. Now THAT is planned obsolescence. My second iPad is at 5 years old and yeah Ive just replaced it. And for what it is worth, the new one is better. The fridge, on the other hand, is a fridge. But would like to know what use I could get out of my otherwise physically working iPad 1, which now has almost no apps, and was obsolete anyway by the time it left the shop.

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.

Not a big deal

[dromgodis]

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.

What's the problem here?

[dromgodis]

If you don't like it, don't use it.

If you get paid to use it, be happy.

Re:python is a trainwreck

[TheRaven64]

Why didn't Apple give Mac OS X (AKA NeXTSTEP, AKA macOS) a different name that wouldn't be confused with Mac OS (AKA System, AKA System Softwware), given that they're completely different and basically incompatible operating systems?

I don't know about you, but I was able to run all of the MacOS 9 applications that I tried on Mac OS X. I started playing Diablo II again recently: Blizzard only released a native OS X installer a few years ago, prior to that the installer on the disk was a classic binary and needed to run in the emulator (which only worked on PowerPC, making it impossible to install on modern Macs).

Re:python is a trainwreck

[Rockoon]

...either way, the new language was going to be a direct competitor to the old language, so yes it was the "best" thing.

Re:Dudes should not wear fedoras

[Buchenskjoll]

Are you saying Indiana Jones, Johnny Depp and Perry the Platypus aren't men?

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:pythonx.y

[Junta]

In other words, python 2 got stable after the developers got bored of it and stopped fucking around with it.

It's interesting because python isn't too shabby in terms of nice looking syntax, but the developers are so damn fickle and screw with things within a release because they lack the patience/discipline to tolerate something 'ugly' for the sake of compatibility...

Fun fact...

[Junta]

Google's little recruitment test is still explicitly python 2.

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.

Re:Fedora should focus on its real problems.

[Etcetera]

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.

Pretty sure you're trolling, but I do take issue with this. RPM is perfectly fine, especially compared to raw .dkpg (spec files are comprehensible, and the ability to have a %verifyscript alone is a major, major win)). In regards to apt, even yum (with its plugin ecosystem) had a number of benefits over apt-get and cousins. I'm no fan of DNF and still consider it to be a classic case of someone's pet project and pet API winning out solely because the conservatives yelling "stop" were looking away for a moment, but this is in line with all the other bone-headed things Fedora was doing around that time... :/