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.
Fedora is now gathering feedback on a Wiki page explaining the switch.
Re: (Score:2)
add `python2` and deprecate `python` (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
Re:add `python2` and deprecate `python` (Score:5, Interesting)
/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.
Re: (Score:2)
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: (Score:2)
Except that Python's upstream concurs.
Re: (Score:1)
Python 2 and Python 3 are similar but different languages, ...
Or, using the Python 3 comparison operator: Python2 ~==~ Python3
Re: (Score:2)
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: (Score:2)
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...
Re: (Score:2)
I thought even in the official Python documentation, you should never make /usr/bin/python -> python3? python3 should always be called explicitly.
Re: (Score:1)
Only if python3/4 was backwards compatible with python2 this wouldn't be a problem. Python is the systemd of programming languages.
PEP 394: /usr/bin/python should not be python3 (Score:5, Informative)
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.
Re: (Score:3)
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 (Score:4, Insightful)
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: (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.
Re:PEP 394: /usr/bin/python should not be python3 (Score:5, 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.
Re: PEP 394: /usr/bin/python should not be python (Score:4, Insightful)
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.
Fuck planned obsolecence! (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 (Score:5, Informative)
Not a big deal (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 Py
What's the problem here? (Score:1)
If you don't like it, don't use it.
If you get paid to use it, be happy.
Re: (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..
Re: (Score:2)
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)
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: // 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 polymorphic division: 5 / 2 = 2 and 5.0 / 2 = 2.5. In Python 3, you need to use two different division operators:
* Python 2 has simple ASCII strings and unicode str
Re: (Score:1)
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: (Score:2)
: // 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
Re: (Score:2)
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: (Score:2)
Re:PEP 394: /usr/bin/python should not be python3 (Score:5, 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.
Re: (Score:2)
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 th
Re: (Score:2)
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 mome
Re: (Score:3)
PEP 394:
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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: (Score: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
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
Why didn't they just give Python 3 a different name entirely?
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
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!
Re: (Score:3)
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 ha
Re: (Score:2)
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: (Score:2)
I think you mean "this is almost as bad as the disaster know as Perl"
Re: (Score:3)
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
Python 3 should be called python3 (Score:1)
And not python. It broke compatibility and there are a ton of projects that have little use for the new major version.
Re: (Score:2)
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...
Why stop there? (Score:2)
Why not just eliminate Python completely and free us all from it's terrible reign? ;)
Re: (Score:3)
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.
python2 == this decade's XP (Score:2)
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?
Fun fact... (Score:2)
Google's little recruitment test is still explicitly python 2.