Apple Finally Removing Python 2 in macOS 12.3

[DrV]

I, too, am happy with the move. Apple's communication on this has been woeful. I think they gave the impression Python would be removed in Big Sur. But they didn't. So, those of us waiting to update our applets to point to Python3 were left wondering. So, now we now.

Apple's communication and attitude toward Python leaves some room for improvement. But the move is really to the right direction. I have been bitten too many times by getting the ancient version after typing python on the command line.

If I really need an old version, then:

pyenv local 2.7.16 python my_awfully_old_script.py

I am afraid Python is moving so fast (relatively speaking), that creating a good Python support by an OS is difficult. Shipping the newest version may not be the right answer, either. Any heavy user will need some Python environment/version control.

 

[funkypepper]

I, too, am happy with the move. Apple's communication on this has been woeful. I think they gave the impression Python would be removed in Big Sur. But they didn't. So, those of us waiting to update our applets to point to Python3 were left wondering. So, now we now.



Absolutely. Instead, Apple recommend that developers include a Python3 runtime with every app. Pity the poor users who might end up with a dozen or more copies of Python3 hidden away in the various apps they like – and every version from 3.8 onwards.

To be fair, Python versioning scheme is just awful. They messed up with the 2.x-3 switch, and now they still continue to mess up with their incremental numbers.

 

[Tagbert]

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.

These changes were not snuck in. The python change was announced a couple of major versions ago and the file provider change was announced at WWDC un June as happening in Mac OS 12.

 

[dwaite]

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.

Process for deprecating/obsoleting a feature that Apple has is:

1. Apple warns developers it is getting removed
2. Optionally, Apple tells users to complain to developers that the software is about to break (e.g. warning users since the vendor is acting irresponsibly)
3. Software breaks

It is expected there will be at least one major version change between #1 and #2/3. You aren't guaranteed any of these will happen on a dot-zero release, although #1 and #3 _usually_ do.

It is nice when these happen on a dot-zero release, as those usually have several months of beta.

I for one am really happy it has been removed, as python 2.7 has been EOL for two years and is no longer getting security updates. I do not want to find out in a post-mortem that I accidentally was relying on an ancient system python.

It may very well be that issues in 2.7 have come up that prompted Apple to remove it ~6 months earlier than planned.

For those using python in your apps, you should skip using system python and instead bundle python directly into your app.

For those who need python 2.7 support still for scripts - I mean, set some priorities, you've had 14 years to move to version 3. After making plans for how you are going to fix your dependency on obsolete and unmaintained upstream software, you can see if a 2.7 version is still available under homebrew.

 

[maxoakland]

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.

The problem is they aren’t replacing it with Python 3, and that’s obnoxious

 

[maxoakland]

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.

Apple’s not including Python3, though, which is a problem

 

[Tagbert]

Apple’s not including Python3, though, which is a problem

Now you can install the version that you need for your scripts and not have to worry about conflicts.

 

[KeeeeenW]

The use of “finally” means the author of this article is not a programmer. There are many legacy scripts depending on the python 2 runtime. It is going to be a backwards compatibility issue for many people who would be forced to spend time fixing the dependency.

 

[Solomani]

Hmmm. Apple recommending devs to bundle runtimes with their apps. Wouldn't that be a great way to introduce trojans?

 

[Notfroggy]

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.

Not sure what reality you exist in but Brew always works well for me. It is clear where it has put stuff, installs in user space and is easy to remove stuff also.

However, I wouldn't suggest Apple officially support it. I'm quite happy with it as it stands.

 

[Notfroggy]

The use of “finally” means the author of this article is not a programmer. There are many legacy scripts depending on the python 2 runtime. It is going to be a backwards compatibility issue for many people who would be forced to spend time fixing the dependency.

"There are many legacy scripts" ... ?? eh? Either you've scripts that you own so you should update them, or they're from a package in which case don't use the package (if it's dependent on Python 2 it's not trust worthy). This whole culture of blind reliance on dodgy packages is nuts in my view.

 

[ksgant]

First casualty that I've seen: Final Fantasy XIV Online won't even launch. Their launcher errors out right away saying it can't find Python 2.7.

This probably won't affect a ton of people here, but just something to be aware of.

 

[bollman]

The Python organization had a roadmap that said “STOP USING PYTHON 2 by 2015” in 2008. They kept changing their roadmap, FINALLY sticking to their guns in 2020. That’s 5 years of extensions even before Apple factored into it. That’s REALLY on the developer.

I do not give 2 sh*ts about Python 2, we did exhaustive work to remove all python-stuff from our org about a year ago.
What matters is that they say when, not "in the future", that does not help with planning. What is "the future"? Next release? In 2 years? Why is it up to Apple to decide how much time we need? Would it really have hurt anything to say that "python 2 support will be removed Q1 2022"? Or, gasp, perhaps they just don't know when? Perhaps it's NOT planned? (hint: that's my guess, at first meeting planning the next release: "Dudes, this thing here, we said we would get rid of it a few years back, perhaps do it now?)

The problem with Apple is that you can never really get any straight answers, at least not if if factor in "time". No, there will be no release dates until it is imminent. "Do you still support this?"-questions are usually answered with a sales pitch that needs to be deciphered and analysed by the NSA to try to get the underlying meaning.
It is opposite anything any enterprise would want and I'm still flabbergasted that Apple can get into the enterprise with such lousy communication with their customers.

 

[Unregistered 4U]

What matters is that they say when, not "in the future", that does not help with planning.

In any organization I’ve been in, we make “what to do, when” based on developer capacity and priority not when Apple says, “ok NOW!” “This will go away in the future” would automatically be a pretty high priority primarily because the end date is unknown. This is ONLY for organizations I’ve been in, of course. I understand that many may operate differently and I’ve been fortunate.

Based on some of the telemetry that Apple receives from developers (from the systems and just communicating with developers), I wouldn’t doubt that they just have an internal metric that says “when usage falls below n% leave it out of the next release”. As the Python org found out, when you give a date, all that happens is developers wait until the last minute then complain that however much time they were given isn’t enough. Apple could have said 2 years and there would be folks in December 2022 yelling that THERE’S NOT ENOUGH TIME… because they started on December 1st 2022. Making the decision to deprecate but not giving a date gets the largest number of folks to prioritize it sooner rather than later (“that’s not deprecated for another 12 months, so lets squeeze this other stuff in for now and come back to that”) and get it done. The few (I’m guessing very few) that are left weren’t going to get it done regardless of the date provided.

 

[Babygotfont]

perl for lyfe

 

[theluggage]

These changes were not snuck in. The python change was announced a couple of major versions ago and the file provider change was announced at WWDC un June as happening in Mac OS 12.

Then it should have happened in 12.0 - when people expected to do a lot of testing, fixing and disposing of abandonware, when there was an extended beta program, and when they had the option of a stable, mature version of MacOS 11 to stick with if they had a problem.

Problem now is that people who verified that everything worked on 12.0 or 12.1 and decided to go ahead and upgrade are committed to Mac OS 12 and pretty much obliged to install the first few point releases to fix other bugs.

I don't know how many times that this can be re-stated but the problem is not the removal of Python 2.7, but the removal of Python 2.7 in a point release that should only be used for essential bug fixes and shouldn't break people's workflows. Remove it in 12.0 - fine. Heck, it could have been removed in 11.0, fine. But if you include it in 12.0 then you're committed until 13.0.

"There are many legacy scripts" ... ?? eh? Either you've scripts that you own so you should update them, or they're from a package in which case don't use the package (if it's dependent on Python 2 it's not trust worthy). This whole culture of blind reliance on dodgy packages is nuts in my view.

Gosh, yes, that is so simple, why didn't anybody else think of it?

Maybe because "you" sometimes means a huge body of users who will have to be taught to use a different package. Maybe because sometimes it takes months to choose, test and adopt a new package across an organisation.

Maybe because "you" sometimes have 101 other urgent jobs to do and/or a manager who has to be convinced of the urgency of any change - and Apple's hand-wavy "this feature will be removed at some undefined point in the future" is really unhelpful.

Maybe because "the scripts you own" depend upon 3rd party libraries which were the recommended solution when you wrote them 10 years ago, so "updating" them means "completely re-writing" them (...and we're not just talking trivial little utilities where you used a "left pad" function to save yourself 10 minutes (actually, I think that was node.js) - they can be substantial libraries that affect the way you write your application - it's not always sensible to re-invent the wheel every time).

Even if lots of people are not going to act (or get approval to take action) until the day their software literally stops working, it would be far better for that to happen with the first release of a major new OS version when reasonable people were expecting that sort of thing and there was a stable, previous OS to stick with.

 

[robd003]

I wonder why they didn't just drop Python 2.7 when they released macOS 12

 

[Unregistered 4U]

Then it should have happened in 12.0 - when people expected to do a lot of testing

“Hey, we’ve got a lot of regression testing for 12.0, why don’t we plan to make that Python change at the same time?”

There’s just SO many ways this could have gone right (and very likely DID go right) for any Python developer.

Plus, if this is something Apple ALWAYS does… I mean… there’s some learning to be done there.

“Every time there’s a deprecation, I wait until I see that it’s ACTUALLY being removed from the beta before I act. However, I’m sure that waiting until Python is removed from the betas won’t bite me the same way the last 14 deprecations did. NO WAY it would happen a 15th time, what are the odds!?”

Probably 100%

 

[adrianlondon]

No, becuase making a major change in a major release gives people more time to fix the issue. (Beta for major releases are 3-4 months, minor releases are 1-2). Also, people expect changes that can break existing workflows to be part of major upgrades, not minor releases.

Can't you just install Python 2 if you want to keep using it?

 

[maxoakland]

Now you can install the version that you need for your scripts and not have to worry about conflicts.

I suppose but that’s got its own issues. Maybe that is better though

 

[chucker23n1]

The use of “finally” means the author of this article is not a programmer. There are many legacy scripts depending on the python 2 runtime. It is going to be a backwards compatibility issue for many people who would be forced to spend time fixing the dependency.

Python 3 was introduced in 2008.

Python 2 stopped receiving security patches in 2020.

People have had 14 years to modernize their code. And today, you can still run Python 2 if you absolutely must, by installing it yourself.

 

[theluggage]

People have had 14 years to modernize their code. And today, you can still run Python 2 if you absolutely must, by installing it yourself.

...which only means that Apple have had 14 opportunities to remove it from MacOS as part of the major, annual upgrade when people were expecting breaking changes and scheduling testing/upgrades.

This is not people asking for Python 2 to be kept around for ever - it's about people wanting Apple to follow basic industry good practice with their software release cycle: if you're going to remove a feature, do it at a major release, not a point update that people need to install for bug fixes etc.

Anyway, the Python 2 to 3 update was a major shambles - create a language, wait for it to become hugely popular and then decide the syntax is not quite the way you want it and release a new version which breaks virtually all existing code (not just rare cases). We're talking about things like the print statement suddenly requiring brackets. That created a vicious circle where the world was flooded with libraries, teaching materials etc. that needed substantial re-writing for Python 3 so developers had to delay switching to 3.

...but at least they saved the changes for 3.0 and didn't stick them in a point release....

 

[chucker23n1]

...which only means that Apple have had 14 opportunities to remove it from MacOS as part of the major, annual upgrade when people were expecting breaking changes and scheduling testing/upgrades.

Apple announced they were going to remove it in June 2019. Now they have. I would've preferred if they had done so in a major release (12.0 or 13.0), but they did give ample warning.

This is not people asking for Python 2 to be kept around for ever - it's about people wanting Apple to follow basic industry good practice with their software release cycle: if you're going to remove a feature, do it at a major release, not a point update that people need to install for bug fixes etc.

Yeah, I agree about that part. They did, however, announce it at a major release, namely with 10.15 Catalina.

Anyway, the Python 2 to 3 update was a major shambles - create a language, wait for it to become hugely popular and then decide the syntax is not quite the way you want it and release a new version which breaks virtually all existing code (not just rare cases). We're talking about things like the print statement suddenly requiring brackets. That created a vicious circle where the world was flooded with libraries, teaching materials etc. that needed substantial re-writing for Python 3 so developers had to delay switching to 3.

Yeah, but that's kind of not Apple's fault. Perl went the different way of instead ultimately giving Perl 6 an entirely different name (Raku). Which now means few people use Perl and even fewer people use Raku, so maybe that wasn't quite the right path.

 

[SouthPalito]

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.

i agree. this is common sense.

 

[4nNtt]

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.

Use of semvar isn't what is important, it is use of a semvar compatible distribution. Since 2.7 has been unsupported for security updates, we are beyond worrying about breaking code. I edited my original post for more clarification.