Slashdot Mirror


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.

94 comments

  1. Dudes should not wear fedoras by Anonymous Coward · · Score: 0

    It is really a bad look and proves they are not packing a python

  2. add `python2` and deprecate `python` by Tora · · Score: 5, Insightful

    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

    --
    tora
    1. Re: add `python2` and deprecate `python` by Anonymous Coward · · Score: 0

      The problem this doesn't solve is needing to include python2.7 in the install media.

    2. Re:add `python2` and deprecate `python` by KiloByte · · Score: 4, Interesting

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

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    3. Re:add `python2` and deprecate `python` by Anonymous Coward · · Score: 0

      People have had 15 years to prepare for the change.

    4. Re:add `python2` and deprecate `python` by Anonymous Coward · · Score: 0

      I use Gentoo and my /usr/bin/python has been Python 3 for well over a year. No problems whatsoever. Also, at work we use Python extensively and converting to Python 3 wasn't trivial, but it wasn't the end of the world either.

      I understand that this change would be a problem 3 or 4 years ago, but right now, that widespread and catastrophic breakage you mention is a myth, as many high profile Python libraries have already moved to Python 3, and many applications have already converted.

      Breakage - where it happens - more likely in poorly maintained projects. But old crap software shouldn't be preventing your distro from moving toward to future. Especially distros that lead the charge, so to speak, and adopted an init system with no proven track record of reliability (and which, just to pick a totally random example, grants your processes root privileges if your username happens to start by a digit... sigh).

      Now, with regards to Python 2, the goal of the Python developers is to deprecate Python 2 sometime in 2020. There has been ample warning about this, but - again, unsurprisingly - distros are still dragging their feet. Some libraries have already announced a roadmap for deprecating support for Python 2.x. Anyone who's been paying attention knows that Python 2 has its days numbered and there's no amount of whining that will stop it because this has been the stated goal since the beginning.

      However, I can foresee that sometime in 2022 Debian will still be backporting patches to Python 2.x just to keep their creaky distro running, all in the name of "stability". Because that's what they do...

      There just is no helping some people.

    5. Re:add `python2` and deprecate `python` by Anonymous Coward · · Score: 0

      Python 2 was released 17 years ago in 2000, python 3 wasn't released until 2008 so less than 10 years ago. Or were you talking about perl 6 which did start in 2000 although the first interpreter was 2005.

    6. Re:add `python2` and deprecate `python` by petermgreen · · Score: 1

      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.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    7. Re:add `python2` and deprecate `python` by KiloByte · · Score: 1

      Except that Python's upstream concurs.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    8. Re:add `python2` and deprecate `python` by guruevi · · Score: 0

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

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    9. Re:add `python2` and deprecate `python` by fahrbot-bot · · Score: 0

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

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

      --
      It must have been something you assimilated. . . .
    10. Re:add `python2` and deprecate `python` by SumDog · · Score: 1

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

    11. Re:add `python2` and deprecate `python` by fahrbot-bot · · Score: 1

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

      --
      It must have been something you assimilated. . . .
    12. Re:add `python2` and deprecate `python` by Anonymous Coward · · Score: 0

      You obviously should start preparing before the actual release. It's not like python is developed in the dark and no one knew about python 3 until they released it.

    13. Re:add `python2` and deprecate `python` by Kjella · · Score: 1

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

      --
      Live today, because you never know what tomorrow brings
  3. PEP 394: /usr/bin/python should not be python3 by caseih · · Score: 5, Informative

    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.

    1. Re:PEP 394: /usr/bin/python should not be python3 by Njorthbiatr · · Score: 2

      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.

    2. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 4, Insightful

      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.

    3. Re:PEP 394: /usr/bin/python should not be python3 by Rockoon · · Score: 1

      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

      --
      "His name was James Damore."
    4. Re:PEP 394: /usr/bin/python should not be python3 by truedfx · · Score: 2
      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.

    5. Re:PEP 394: /usr/bin/python should not be python3 by Dutch+Gun · · Score: 2

      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.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    6. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 1

      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.

    7. Re:PEP 394: /usr/bin/python should not be python3 by 93+Escort+Wagon · · Score: 4, Insightful

      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.

      --
      #DeleteChrome
    8. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 2, Interesting

      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.

    9. Re:PEP 394: /usr/bin/python should not be python3 by Doogie5526 · · Score: 1

      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.

    10. Re:PEP 394: /usr/bin/python should not be python3 by JanneM · · Score: 4, Informative

      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.

      --
      Trust the Computer. The Computer is your friend.
    11. Re:PEP 394: /usr/bin/python should not be python3 by caseih · · Score: 1

      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!

    12. Re: PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      LMAO, imagine someone telling the author of a program written in C a decade ago that they're stupid because they didn't rewrite their entire program in a backwards incompatible new version of C

      Oh that's right nobody would ever say that because C was designed properly from the start. Also C developers wouldn't be so uppity about it even if it were the case.

    13. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 1

      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!

    14. Re:PEP 394: /usr/bin/python should not be python3 by Billly+Gates · · Score: 2

      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?

    15. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      That "latest greatest thing" is _9 years old_

      Yes, python 3 has been fucked for 9 years. Until I can take well tested python 2 code and run it against python 3, go fuck yourself.

      But even morons like you still have another 2 years to finally change that one function that won't work.

      See here is what you clearly aren't fucking getting. Why I should I *need* to modify working code that has been PROVEN reliable, then HOPE that no new bugs were introduced in the process. That also means the code needs to be run past the QA team who needs to test all of it, then users need to test it after that. That's a lot of time and money that just isn't fucking worth it so I can stroke Guido's ego.

    16. Re: PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      LMAO, imagine someone telling the author of a program written in C a decade ago that they're stupid because they didn't rewrite their entire program in a backwards incompatible new version of C

      Well, sometimes you get the random C++ coder who does exactly that :P

    17. Re:PEP 394: /usr/bin/python should not be python3 by Dutch+Gun · · Score: 1

      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.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    18. Re: PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      Yes, python 3 has been fucked for 9 years. Until I can take well tested python 2 code and run it against python 3, go fuck yourself.

      And yet my perfectly working C++ 98 code now fails to compile on gcc 6 with c++11 features enabled because of all the deprecation warnings about auto_ptr. Auto ptr is still available in c++11 and not removed until c++17.

      So your complaints are hardly valid. All languages make changes that have backwards compatibility issues. The Python2/3 changes largely make parts of the language internally consistent and can largely be automated. IIRC code updated to be compatible with python 3 should run on python 2 still so long as the programmer didn't also go on to leverage P3-only features during the conversion.

    19. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      _9 years old_

      And that 9 year old version of Python adds basically nothing new or interesting. In fact, it's demonstrably worse in most cases because it's slower than the already dog slow Python 2. You should have taken the chance to address real problems. Now I get to watch your shitty dynamically typed mess die.

    20. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      Someone will step up and maintain Python 2.7. Probably RedHat or Google. Google alone has millions of lines of Python that will never be ported to Python 3. Some of it will be ported to other languages but there's absolutely no chance of it going to Python 3.

    21. Re: PEP 394: /usr/bin/python should not be python3 by sjames · · Score: 1

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

    22. Re:PEP 394: /usr/bin/python should not be python3 by Dutch+Gun · · Score: 1

      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?

      --
      Irony: Agile development has too much intertia to be abandoned now.
    23. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      Flame Received! Sending Flashback:

      python3 as a breaker-of-standards should not exist. (I don't give a damn about unicode! OTOH I do a significant amount of bit manipulation; P3 breaks existing code ) If you want a new language, great - but make it a new language.

      Oddly the CAPTCHA for this AC post is 'prudence' Highly appropriate!

    24. Re:PEP 394: /usr/bin/python should not be python3 by gl4ss · · Score: 1

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

      --
      world was created 5 seconds before this post as it is.
    25. Re: PEP 394: /usr/bin/python should not be python3 by TheRaven64 · · Score: 4, Informative

      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.

      --
      I am TheRaven on Soylent News
    26. Re:PEP 394: /usr/bin/python should not be python3 by TheRaven64 · · Score: 1

      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.

      --
      I am TheRaven on Soylent News
    27. Re:PEP 394: /usr/bin/python should not be python3 by Bongo · · Score: 1

      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.

    28. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      I'm glad someone mentions HPC. I once was doing some calculation heavy stuff (it may have been within the Project Euler, but I can't be certain). I tried implementing the same stuff in Python2 and Python3. Without using extra stuff (Numpy, Scipy and so on) and staying as much as possible within the Python standard tools, whatever I was doing was 10% faster on Python2 than on Python3.

      Now, I didn't explore it thoroughly, but if the same applies more generally, most scientists will stick to Python2 for a while. Performance matters! We see plenty of code still in Fortran, why would changing from old python to new python be any different?

    29. Re:PEP 394: /usr/bin/python should not be python3 by Junta · · Score: 1

      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.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    30. Re:PEP 394: /usr/bin/python should not be python3 by Sepulep · · Score: 1

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

    31. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      If you care about 10%, why on Earth are you writing code in Python?

    32. Re: PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      How about just compiling with -Wno-deprecated-declarations if you insist on compiling with -Werror. Or you know, compile with -std=gnu++98 or -std=c++98 if you need to.

      Or you know, you could read the fucking man pages for g++

    33. Re:PEP 394: /usr/bin/python should not be python3 by Billly+Gates · · Score: 1

      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.

    34. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      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.

      Huh? A current zSeries mainframe running a current version of z/OS (say z/OS 2.1, not under zVM) will run 'old COBOL' native in batch and not at all in CICS. If you need it to run in CICS you buy a non-IBM runtime support product which replaces the runtime support removed by IBM a few years ago and allows it to run as native code.

      Emulators and VMs don't have anything to do with it.

         

    35. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      I always thought that was ridiculous in C language : try to divide something by 2.0 instead of 2 to please the weak typing system. Wondering if 2. works or not. And integer division was just rare past primary school. Fractions don't care and calculators rarely do it :)

    36. Re:PEP 394: /usr/bin/python should not be python3 by TheRaven64 · · Score: 1

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

      --
      I am TheRaven on Soylent News
    37. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      COBOL is 58 years old and new programs are written in COBOL. Now what?

    38. Re:PEP 394: /usr/bin/python should not be python3 by Anonymous Coward · · Score: 0

      Because the language doesn't suck to write programs in.

      There's a tradeoff but using C and hating your life is not a good tradeoff.

      Also, which other languages that have as many scientific libraries as Python available today did you have in mind?

  4. Legacy Support Needs to be Mandated by Anonymous Coward · · Score: 0

    There is no good excuse for this sort of obsolescence. Fedora has the ability to both one time and dynamically recompile as well as emulate. They and any OS manufacturer can fix this problem. It is time for regulations that enforce a rule that OS companies stop creating obsolescence but must instead maintain legacy support.

    1. Re: Legacy Support Needs to be Mandated by Anonymous Coward · · Score: 0

      Like they'd listen; if they were that committed to not breaking the world they never would have pushed a certain new init-but-oh-so-much-more system on everyone.

    2. Re:Legacy Support Needs to be Mandated by Anonymous Coward · · Score: 0

      It is time for regulations that enforce a rule that OS companies stop creating obsolescence but must instead maintain legacy support.

      Yeah, that's fine as long as the maximum penalty for Fedora not complying with your law is equal to the license fee you paid to run Fedora.

  5. python is a trainwreck by Anonymous Coward · · Score: 0

    Python is a complete trainwreck. So much crap still relies on Python 2 and them some needs Python 3. I mean they might as well be completely different languages. Why didn't they just give Python 3 a different name entirely?

    This is almost as bad as the disaster known as Perl 6.

    1. Re:python is a trainwreck by Anonymous Coward · · Score: 0

      Python is a complete trainwreck. So much crap still relies on Python 2 and them some needs Python 3. I mean they might as well be completely different languages. Why didn't they just give Python 3 a different name entirely?

      They did: "Python 2" != "Python 3". See? Entirely different name.

      This is almost as bad as the disaster known as Perl 6.

      Well, Perl is a di

      Actually, never mind. Perl is history anyway.

    2. Re:python is a trainwreck by Rockoon · · Score: 1

      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

      --
      "His name was James Damore."
    3. Re:python is a trainwreck by Luthair · · Score: 1

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

    4. Re:python is a trainwreck by Zobeid · · Score: 0

      Why indeed? Well, it's not like this is some new tactic that we've never seen before in the annals of computering.

      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? Could it be that they were deliberately attempting to conflate the two in the minds of their customers? Gasp!

    5. Re:python is a trainwreck by murdocj · · Score: 1

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

    6. Re:python is a trainwreck by LostMyBeaver · · Score: 2

      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.

    7. Re:python is a trainwreck by TheRaven64 · · Score: 1

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

      --
      I am TheRaven on Soylent News
    8. Re:python is a trainwreck by Rockoon · · Score: 1

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

      --
      "His name was James Damore."
    9. Re:python is a trainwreck by Junta · · Score: 2

      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.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    10. Re:python is a trainwreck by Anonymous Coward · · Score: 0

      They should have compromised by calling Python 3 'Pythonesque'

  6. righton...!! by Anonymous Coward · · Score: 0

    Editordavid

    Thanks for refreshing my limited faith in the /. werld..
    Finally Some news for nerds..!!!!!
    Thank you

  7. Fedora should focus on its real problems. by Anonymous Coward · · Score: 0

    So there we have it. The Python developers themselves make this a total non-issue in a sensible way.

    Now that this Python "problem" is out of the way, perhaps it's time for the Fedora maintainers to focus on the real problems plaguing their distro.

    The first problem is systemd, obviously. The solution to this Windowsification of Linux is clear: get rid of it, and use OpenRC instead. Problem solved.

    The second problem is GNOME 3. It can't be salvaged at this point. Like systemd, it should be thrown out. It could be replaced with MATE, which is based on the much more usable GNOME 2. Problem solved.

    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.

    1. Re:Fedora should focus on its real problems. by Etcetera · · Score: 1

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

  8. Python 3 should be called python3 by Anonymous Coward · · Score: 1

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

  9. quick hacks bite you in the ass by Anonymous Coward · · Score: 0

    you script a prototype.
    you compile a program for distibution.

  10. pythonx.y by Anonymous Coward · · Score: 0

    It needs major/minor versioning.

    Seems like far too many people forget, but python has *NEVER* been stable between minor releases in the same major number. That in fact is the whole reason why we have been on Python 2.7 for so long, it was the first 2 release that didn't break language constructs/abis/expectations in the 2 series, and the patchlevel releases more or less ended up only being bugfixes, resulting in code against the 2.7 releases being mostly reliable and compatible on any other release. In contrast many things broke between 2.4 and 2.5, 2.5 and 2.6, and variations between those. Someone a few years back was complaining exactly about this, and how they had code developed for 2.5 or something and the client worked on 2.4 and the server on 2.6, but neither ended up working on 2.5 because certain assumptions in the language parser changed from version to version and thanks to a lack of pedanticism in their code, different assumptions were made by different interpreters/modules that broke each in subtle ways.

    Python needs all releases major and minor versioned, and if scripts are supposed to be truly 'generic' then there should perhaps be a 'python-generic' or 'python-majorversion' symlink if the application regression tests successfully against all of a specific major-version of python's minor versions.

    1. Re:pythonx.y by Junta · · Score: 1

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

      --
      XML is like violence. If it doesn't solve the problem, use more.
  11. Why stop there? by Gravis+Zero · · Score: 1

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

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:Why stop there? by Billly+Gates · · Score: 2

      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.

  12. HAHA by sproketboy · · Score: 0, Offtopic

    More Linux fail. I love it.

  13. python2 == this decade's XP by Billly+Gates · · Score: 1

    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?

  14. Fuck planned obsolecence! by knorthern+knight · · Score: 1

    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.

    --

    I'm not repeating myself
    I'm an X window user; I'm an ex-Windows user
    1. Re:Fuck planned obsolecence! by Bongo · · Score: 1

      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.

    2. Re:Fuck planned obsolecence! by Anonymous Coward · · Score: 0

      Python 2.7.13 was released 2016-12-17, not that long ago.

      It seems they are still doing bug fixes and the like, but they have stopped putting in features.

      Personally, I like the new defaults that were put in for Python 3 (dict.items() returning a view is a the best call, making me remember to use dict.viewitems() every time, not so great).

  15. python fucking sucks by Anonymous Coward · · Score: 0

    get these toy languages out of here

  16. Re: PEP 394: /usr/bin/python should not be python by Anonymous Coward · · Score: 0

    Warnings do not cause your compile to fail unless you use -Werror, in which case you explicitly asked the compiler to fail rather than just warn you about things like that.

  17. Not a big deal by dromgodis · · Score: 1

    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.

  18. What's the problem here? by dromgodis · · Score: 1

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

    If you get paid to use it, be happy.

  19. begs to differ by Anonymous Coward · · Score: 0

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

    The creator of python begs to differ.

  20. Re: PEP 394: /usr/bin/python should not be python by Anonymous Coward · · Score: 0

    "because C was designed properly from the start."

    What's the size of an int again ?

  21. Re:Dudes should not wear fedoras by Buchenskjoll · · Score: 1

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

    --
    -- Make America hate again!
  22. Fun fact... by Junta · · Score: 1

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

    --
    XML is like violence. If it doesn't solve the problem, use more.
  23. perl by Anonymous Coward · · Score: 0

    and old perl still lives on. long live perl

  24. Python's Heal by Anonymous Coward · · Score: 0

    This has always been an issue with Python, and the one reason I haven't really wanted to learn it.

  25. Re: PEP 394: /usr/bin/python should not be python by AndroSyn · · Score: 4, Insightful

    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.