Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Python Programming Linux

It Will Take Fedora More Releases To Switch Off Python 2 (phoronix.com) 94

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.
This discussion has been archived. No new comments can be posted.

It Will Take Fedora More Releases To Switch Off Python 2

Comments Filter:
  • by Tora ( 65882 ) on Sunday July 30, 2017 @05:47PM (#54910387)

    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

    • by KiloByte ( 825081 ) on Sunday July 30, 2017 @06:00PM (#54910473)

      /usr/bin/python is not going to ever point to python3 in Debian, at least according to the maintainer [debian.org]. 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.

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

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

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

        • 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: ~=!=~

          • by Kjella ( 173770 )

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

      • by SumDog ( 466607 )

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

    • by guruevi ( 827432 )

      Only if python3/4 was backwards compatible with python2 this wouldn't be a problem. Python is the systemd of programming languages.

  • by caseih ( 160668 ) on Sunday July 30, 2017 @05:47PM (#54910389)

    Python developers themselves have stated in PEP 394 [python.org] 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.

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

      • by Anonymous Coward on Sunday July 30, 2017 @06:00PM (#54910477)

        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.

        • by 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.

          • by 93 Escort Wagon ( 326346 ) on Sunday July 30, 2017 @07:17PM (#54910803)

            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.

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

            • by Bongo ( 13261 )

              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

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

      • 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: (Score:2, Interesting)

        by 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 str

        • by 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!

        • by gl4ss ( 559668 )

          : // 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 tw

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

      • by JanneM ( 7445 ) on Sunday July 30, 2017 @08:01PM (#54910961) Homepage

        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.

    • by truedfx ( 802492 )
      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.

    • 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 t

      • 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.
      • by caseih ( 160668 )

        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, bec

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

      • 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 VBScr

        • 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 func

        • by Bongo ( 13261 )

          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.

          • 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

  • by Anonymous Coward

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

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

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

  • 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?

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

"my terminal is a lethal teaspoon." -- Patricia O Tuama

Working...