Apple Finally Removing Python 2 in macOS 12.3

[MacRumors]

Apple will no longer bundle Python 2.7 with macOS 12.3, according to developer release notes for the upcoming software update. Python 2 has not been supported since January 1, 2020 and no longer receives any bug fixes, security patches, or other changes.

Apple says that developers should use an alternative scripting language going forward, such as Python 3, but it's worth noting that Python 3 also does not come preinstalled on macOS. Developers can run the stub /usr/bin/python3 in Terminal, but it prompts users to install Xcode developer tools, which includes Python 3.

Apple warned that future versions of macOS would not include Python 2.7 in macOS Catalina's developer release notes back in 2019. At the time, Apple said Python 2.7 was included in macOS for compatibility with legacy software.

"If your software depends on scripting languages, it's recommended that you bundle the runtime within the app," said Apple.

Article Link: Apple Finally Removing Python 2 in macOS 12.3

 

[ArrayDecay]

Excellent news.

 

[Bokito]

Apple is not really working towards being semver friendly this week. Removing Python 2.7 in a dot release and also making older cloud storage apps read-only. I don't care they do this (it's for the greater good), but they shouldn't do it in a point release, especially ones you can't skip as they contain security fixes.

Fortunately I'm not affected by any of the changes, but it's just bad business.

 

[4nNtt]

Apple is not really working towards being semver friendly this week. Removing Python 2.7 in a dot release and also making older cloud storage apps read-only. I don't care they do this (it's for the greater good), but they shouldn't do it in a point release, especially ones you can't skip as they contain security fixes.

Fortunately I'm not affected by any of the changes, but it's just bad business.

For the last year, first time you try to use Python 2 the operating system displayed a warning similar to the one that was displayed for 32-bit apps back in Mohave. I think the warning is only displayed if you don’t have developer tools installed. Any non-developers affected should know by now and developers should be able to easily switch to a semvar friendly version.

I think it is likely Apple will continue to ease out of the yearly cadence for features. They might show some user facing features off up to a year early, but they will just come out when they are ready. Secrecy makes sense up to a point, but you need to get developers to adopt the features. Forcing a feature that is ready to ship to wait for a release cycle is also an anti-pattern. I think major updates will be iOS style at some point. Every year macOS has inched closer to that. They are nearly there now. I wouldn’t be surprised if M1 Macs get the iOS update treatment this time around.

EDIT: There seems to be some confusion about semvar here. Apple is being semver friendly by requiring the use of pyenv or similar to allow multiple concurrent versions of of Python that are widely compatible. Keeping an old version of Python around that is not receiving LTS updates has nothing to do with semvar compatibility.

 

[weup togo]

So two major binary compatibility breakages in a January dot release. Apple’s culture has radically changed for the worse. It’s not a “platform” if it’s falling apart beneath you. It’s a trapdoor.

 

[theluggage]

I think the warning is only displayed if you don’t have developer tools installed. Any non-developers affected should know by now and developers should be able to easily switch to a semvar friendly version.

You might want to try clicking on the link to find out what "semver" actually refers to.

The point is that changes like this, which break existing code, should happen at major releases, when reasonable people expect to have to do the research and deal with some disruption to their work - not snuck in with a point release alongside essential bug fixes and security updates. Adequate warning was given that it would disappear sometime but that's only so much use without giving a clue about when it would be removed, and then vanishing it overnight. Getting rid of legacy software dependencies isn't always straightforward and people need clarity about when things will be removed.

 

[foobarbaz]

Apple is not really working towards being semver friendly this week.

Semver works for libraries not for consumer products. Otherwise we'd be using macOS 75.0.0 it this point.

 

[averagenerd81]

Apple is not really working towards being semver friendly this week. Removing Python 2.7 in a dot release and also making older cloud storage apps read-only. I don't care they do this (it's for the greater good), but they shouldn't do it in a point release, especially ones you can't skip as they contain security fixes.

Fortunately I'm not affected by any of the changes, but it's just bad business.

Since security updates have not been provided in two years for 2.x, it is time to get rid of it with anyone desiring it can install it on their own. I am sick of being hampered because people refuse to move on, it's two years with no updates. It's dead Jim, move on and make us more secure.

 

[Asbow]

Since security updates have not been provided in two years for 2.x, it is time to get rid of it with anyone desiring it can install it on their own. I am sick of being hampered because people refuse to move on, it's two years with no updates. It's dead Jim, move on and make us more secure.

I agree.

 

[Soylent Yellow]

Who would even use Python 2 anymore? I have a couple of simple scripts running in Python, and when researching what to write (I am a very very lousy programmer and basically cut, paste and change everything from sites like stackexchange) I /had/ to switch to Python 3 because none of the examples worked in the standard issued Python 2.

 

[deconstruct60]

For the last year, first time you try to use Python 2 the operating system displayed a warning similar to the one that was displayed for 32-bit apps back in Mohave. I think the warning is only displayed if you don’t have developer tools installed. Any non-developers affected should know by now and developers should be able to easily switch to a semvar friendly version.

That just another example of how this just wasn't handled well. Python 2 was desupported in January2020. That six months before Apple shipped the beta to 12 ( Big Sur: WWDC 20 beta -> Released Nov 2020 ) . That is the Fall where the "we are going to drop this in a year" warnings responsibly have gone in. That would have been a year of shipping out date / desupported software.
Fall 2021 they could have pulled it.

I think it is likely Apple will continue to ease out of the yearly cadence for features.

Deprecation and app retirement isn't a "feature". It isn't responsible to do this "Jack in the Box" fashion of "surprise ... this is the actual end of the road". If something is newly deprecated on a major feature release boundary then an entirely reasonable expectation is that it will finally be retired on a major release boundary. ( Not pull a date out of your butt).

If for some reason plan to do something that is outside the normal expectation windows, then communicate that clearly ahead of time. For example, have an explicit , public software phase out roadmap. Oh like Python 2 and 3 have. [ i.e., provided Apple data months and years in advance to come up with a reasonable plan. The Python 2 maintainers didn't drop it on some random, out of the blue date and caught Apple 'flat footed' so they had to scramble to respond. Apple's bumbling down the road here is a more a non plan ... or at very least a failed communication plan. ]

They might show some user facing features off up to a year early, but they will just come out when they are ready.

"new stuff" that folks have zero dependency upon that is mostly fine. Again thought Python is more a foundational library then some refactoring of the GUI on Finder is.

 

[miland]

Apple is not really working towards being semver friendly this week. Removing Python 2.7 in a dot release and also making older cloud storage apps read-only. I don't care they do this (it's for the greater good), but they shouldn't do it in a point release, especially ones you can't skip as they contain security fixes.

Fortunately I'm not affected by any of the changes, but it's just bad business.

The warning about Apple removing at some point the scripting languages was first time communicated in 2019 before release of Catalina - 10.15 (https://developer.apple.com/documen..._15-release-notes#Scripting-Language-Runtimes). If you started new project in that time period and used the builtin python 2.7 against the warning, then it doesn't matter if it happened on MAJOR change or MINOR one.

 

[JosephAW]

MacOS is becoming a bag full of hurt.

 

[nwcs]

I wish Apple would officially sanction the brew project. Give us a real package manager! Then things like this are of little consequence.

 

[averagenerd81]

MacOS is becoming a bag full of hurt.

I see you haven't used Windows before. Just this month I had to refrain from patching my domain controllers because the cumulative update for January sent them into a boot loop. The update to fix that is only available via manual install (it isn't advertised in WSUS or SCCM), but the patch that breaks things still is! So you have to install the broken patch and then the fix for the broken patch.

Removing a 2 year unpatched version of Python that people have been notified about repeatedly being a "bag full of hurt"? Only if you can't read the basic text when you launch python from the CLI:

WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software. Future versions of macOS will not include Python 2.7. Instead, it is recommended that you transition to using 'python3' from within Terminal.

So yeah, totally a "bag full of hurt" ..... totally.

 

[Bokito]

Semver works for libraries not for consumer products. Otherwise we'd be using macOS 75.0.0 it this point.

Well, it would be great if they did adhere to it. That if you upgrade you can expect things to break. Now things can break while installing an update that contains security fixes.

 

[ArtOfWarfare]

It's great that Apple is moving on from Python 2.7.
It's horrible that they're simply removing Python instead of updating to Python 3.

This is a move towards making macOS useless out of the box, like Windows.

We're moving towards some Linux Distro (Ubuntu? Raspian? Steam?) being the best OS.

 

[TriBruin]

Since security updates have not been provided in two years for 2.x, it is time to get rid of it with anyone desiring it can install it on their own. I am sick of being hampered because people refuse to move on, it's two years with no updates. It's dead Jim, move on and make us more secure.

How does NOT removing Python2 hamper you personally? Very curious how something you probably never use still affects you.

 

[jonblatho]

It's great that Apple is moving on from Python 2.7.
It's horrible that they're simply removing Python instead of updating to Python 3.

This is a move towards making macOS useless out of the box, like Windows.

We're moving towards some Linux Distro (Ubuntu? Raspian? Steam?) being the best OS.

Or you can just install Python with conda or pyenv, which you generally should be doing anyway for numerous reasons. If you really insist, you can have a single Python installation on your system (which doesn’t have to be bundled with the OS!), but that gets messy pretty quickly the moment you start working with multiple Python projects.

 

[Xiao_Xi]

I wish Apple would officially sanction the brew project. Give us a real package manager!

Strangely, Windows got an official package manager before macOS.

 

[averagenerd81]

How does NOT removing Python2 hamper you personally? Very curious how something you probably never use still affects you.

Any component of a system that is not maintained (ie; patched) is a potential attack vector that is a problem for any user of a system. If this was not the case, why would Apple want to remove it in the first place?

Python Python security vulnerabilities, CVEs, versions and CVE reports

Python Python security vulnerabilities, CVEs, exploits, metasploit modules, vulnerability statistics and list of versions

www.cvedetails.com

See above for a list of CVEs assigned to Python over time for discovered vulnerabilities. If this were not the case, I would not have constantly be pestered by the endpoint protection I administered for outdated versions of python 2.x that exist on servers at my former employer.

Unpatched software is a major problem in this industry and I wish more companies would move faster to remediate issues like this.

Edit: To further this point, you're right ... I do not use python2 because we have been told for awhile to move on to python3, which is what I use. So .. please, Apple, remove it.

 

[nt5672]

I wish Apple would officially sanction the brew project. Give us a real package manager! Then things like this are of little consequence.

Sorry, but brew is a pot of really bad stew. Sure it works sometimes, is easy to get recipes, but it scatters stuff all over and depending on the recipe, may not clean up after itself. You should only use brew on machines that you regularly reformat. Just saying, so none of the children that use Macs get hurt.

So the alternatives are Fink, but it is out of date and does not currently support Big Sur which is what almost 2 years old. But it does use apt tools.

Then there is MacPorts, which is way better (although not without it faults) for security and reliability as long as it has the port you are looking for. It sucks for Perl ports that every other linux install uses.

In the end, we need a new good package manager. But alas, Apple is moving away from the command line as it is too difficult for the children. So I don't expect that to ever happen.

 

[theluggage]

Semver works for libraries not for consumer products. Otherwise we'd be using macOS 75.0.0 it this point.

It doesn't matter so much that Apple don't stick to the letter of the semver standard - the important bit is to stick to the definition of "major version" as the only point where you knowingly break backwards compatibility. Consumers probably don't need a 3-part version number, but they still need clarity about the "installing this update might break stuff" bit.

Apple themselves have now - with Big Sur - abandoned the idea of having a version number as part of the primary brand name. For OS X the major version number was, effectively, the one after the 10. Now they're counting up from 11 again, but the "major" versions are still clearly the ones announced every year at WWDC, with a whole developer conference to cover the changes in detail and an extensive beta program. Users can (and sensible ones do) choose to run a version behind for stability and to stave off major changes, but when you do upgrade to a major version you're pretty much committed to installing every minor release as it arrives to get the bug fixes and security patches.

 

[dr_lha]

To all the people complaining about this, do you actually think you'll be hurt by this?

Apple have been warning people for years Python 2 is going away. Almost everyone (myself included) who uses python moved to 3 years ago, and most likely doesn't use the system installed version anyway.

Can anyone point to something that will actually break because of this, where the solution isn't just to install python2 using MacPorts/HomeBrew/Anaconda etc?

 

[TriBruin]

Any component of a system that is not maintained (ie; patched) is a potential attack vector that is a problem for any user of a system. If this was not the case, why would Apple want to remove it in the first place?

Python Python security vulnerabilities, CVEs, versions and CVE reports

Python Python security vulnerabilities, CVEs, exploits, metasploit modules, vulnerability statistics and list of versions

www.cvedetails.com

See above for a list of CVEs assigned to Python over time for discovered vulnerabilities. If this were not the case, I would not have constantly be pestered by the endpoint protection I administered for outdated versions of python 2.x that exist on servers at my former employer.

Unpatched software is a major problem in this industry and I wish more companies would move faster to remediate issues like this.

Edit: To further this point, you're right ... I do not use python2 because we have been told for awhile to move on to python3, which is what I use. So .. please, Apple, remove it.

For the record, I am fine with the decision to remove it. However, I don't understand Apple's decision to remove it in a point release versus a major release. They have already kept in the OS for 1 1/2 years, why not another six months?

The issue is that there are thousands of scripts that still call #!/bin/python in Mac Admin toolkits and installed on computers will need to be re-written, either in another scripting language (bash or zsh) or translated to python3. If the admin chooses to go the Py3 route, then a version of Python3 will need to installed as well. (We install a relocatable version of Py3 for our scripting use.)

Fortunately, Mac Admins have been aware of the pending removal for a couple of years. We have been working to track down the scripts and fix the issue. But, it is still a work in progress. It is not even just .py scripts. Bash scripts occasionally call python to perform certain tasks. In fact, for many years, the most popular command to determine the current logged in user used Python. Most of have moved on from that line, but I know for a fact that many vendor scripts still use that call. Back to our vendors to get updated packages with updated post-install scripts.