Apple Finally Removing Python 2 in macOS 12.3

[4nNtt]

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.






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




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

I think most of this is overblown. Software that required embedding (areas where python was used as more than an extension language) was largely in the enterprise IT space that was already used to making operating system compatibility changes. Major programs were ready long before Monterey shipped. Removing open source software that isn't receiving security updates anymore is a good thing. Apple has long encouraged developers to switch away from it to semvar compatible distributions of Python. Python was never a foundational library on macOS. Developers that use it as an extension language have always embedded it. DevOps were the primary users of it and they switched to brew or macports years ago since all of that is on Python3 now.

 

[Unregistered 4U]

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

Yes, but the problem is likely in the area where someone, providing solutions for others, rather than update or modify the way they delivered the solution, put both:
Moving off of Python 2, and
Embedding Python 3 (or getting to the point where you don’t need Python anymore)

as low priorities. Both are things that that take a little time to do but are not insurmountable feats for a developer or a team of developers to do over the course of 12 months… if they’re working really REALLLYYY slowly. Nevertheless, getting something done painfully slow over a year still beats not doing it at all. And I think that’s the core of it. A developer would have had to go against pretty much EVERYTHING that they learned over their career as a developer to be caught out by this.

If a developer is running headlong against every best practice in the book, being surprised by this is the inevitable result. If you look at a pie chart of all the things that could have prevented this from being an issue for the developer “knowledge from Apple of the date when deprecation will occur” is a tiny sliver. Anything you can put the rest of he pie can neatly be defined as “the job of a developer”.

 

[chucker23n1]

Both are things that that take a little time to do but are not insurmountable feats for a developer or a team of developers to do over the course of 12 months… if they’re working really REALLLYYY slowly.

I mean, I've been migrating a .NET 4.x codebase to the .NET Core era, and it's been years. And it'll probably take another year or two. I also still has a client who's on .NET Framework 2.0, from 2005. For complicated reasons, I can't easily upgrade.

Not to mention, infamously, all those massive codebases that are still on COBOL.

So, sometimes, migrations take time. But I can't fault Apple for finally cutting this cord. Just for doing it in a minor release.

 

[name99]

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.

What's not clear is WHY this was done. But assuming "Apple just suck" seems unlikely.

My guess is that in six months or so we will learn of some nasty exploit in Python 2.7 (perhaps theoretical in the past, but recently discovered as weaponized) and Apple felt it was appropriate to deal with the issue via a hard kill of Python 2 (something, as you say, that they've been warning of since 2020) rather than waiting till macOS 13 in September.

 

[Unregistered 4U]

What's not clear is WHY this was done. But assuming "Apple just suck" seems unlikely.

The “why” of killing Python2 support is pretty clear. The Python org doesn’t support it anymore. The why of removing ANY Python? Probably similar to why they remove Java… why have something sitting there as a vector for exploit when the customer isn’t going to use it. And, if the customer wants it, they can download the proper distribution and install it.

 

[pasamio]

It's curious that 12.3 is where Apple are removing a bunch of tech debt. That said this article from 2019 suggests that Python 2.7 was supposed to be gone with macOS "10.16" which obviously became macOS 11 Big Sur and didn't remove it as expected. I'm guessing they finally cleaned up what ever it was they were depending upon it to do in this release.

It also makes one wonder if any of this is connected to what might be coming up with a future OS release and maybe some sort of internal development fork process for the next OS release.

 

[theluggage]

What's not clear is WHY this was done. But assuming "Apple just suck" seems unlikely.

There's no need to look for a sophisticated reason: removing something isn't a huge job, but any change requires some amount of work, testing, documentation changes and "due diligence" to make sure that nothing else depends on it. It would have been a minor, low priority task that just didn't bubble to the top of the agenda until more urgent things had been dealt with.

Reality is that, in the run-up to a ".0" release, breaking changes like that should be prioritised over new features.

The fundamental problem here is that Apple have tied themselves to announcing a new, shiny bell-and-whistle-laden version of MacOS every spring and releasing it every fall, ready or not, because marketing trumps reality - and, surprise, surprise, it is never ready. The beta program is really an alpha program, developers never know what surprises Apple is going to pull with the ".0" (really: beta) release until it lands (...which regular users are nagged to install on day 1 and which is foisted on anybody who buys a new machine in that period). So perhaps we've all got it wrong and should just be living in cynical world where 12.3 is the major, feature-complete, production-ready release...

If a developer is running headlong against every best practice in the book, being surprised by this is the inevitable result.

...which is often because the developer is running headlong against management, customers, budget and time constraints. There seem to be a lot of very fortunate one-man-band "developers" here who've never had to justify their schedules and tasks with management or deal with change-resistant users. Plus a lot of support people who's users are so computer literate that you can just drop them an email saying "just install homebrew and install 2.7 for the moment". If only... Apple can't fix that, they can't fix the Python 2 vs 3 dumpster fire, but they can help developers and admins by following a predictable schedule compliant with industry best practices and tying such changes to major releases with 6+ months' notice.

 

[chucker23n1]

It's curious that 12.3 is where Apple are removing a bunch of tech debt. That said this article from 2019 suggests that Python 2.7 was supposed to be gone with macOS "10.16" which obviously became macOS 11 Big Sur and didn't remove it as expected.

Apple only said “Future versions of macOS”. That some journalist turned that into “they’ve got to mean the next major release” isn’t really relevant.

 

[pasamio]

Apple only said “Future versions of macOS”. That some journalist turned that into “they’ve got to mean the next major release” isn’t really relevant.

I think it's safe to assume if Apple deprecate something that this is your minimum one year warning that it is going to go away and you need to start figuring out alternatives. Apparently over a decade of Python 2 being the end of the line isn't enough and back in the Catalina days Apple specifically called out Python 2.7 as not recommended for use on top of the scripting languages (Python/Perl/Ruby) are going away.

 

[name99]

The “why” of killing Python2 support is pretty clear. The Python org doesn’t support it anymore. The why of removing ANY Python? Probably similar to why they remove Java… why have something sitting there as a vector for exploit when the customer isn’t going to use it. And, if the customer wants it, they can download the proper distribution and install it.

The WHY is not "why is Apple removing Python 2", it is "Why are they removing Python 2 in a dot release? Why not either w/ macOS 12.0 or 13.0?"
I can't believe I have to spell out such an obvious point, but that's the internet for you.

 

[Unregistered 4U]

...which is often because the developer is running headlong against management, customers, budget and time constraints. There seem to be a lot of very fortunate one-man-band "developers" here who've never had to justify their schedules and tasks with management or deal with change-resistant users. Plus a lot of support people who's users are so computer literate that you can just drop them an email saying "just install homebrew and install 2.7 for the moment". If only... Apple can't fix that, they can't fix the Python 2 vs 3 dumpster fire, but they can help developers and admins by following a predictable schedule compliant with industry best practices and tying such changes to major releases with 6+ months' notice.

That’s actually even worse… to consider that, when the dev team, program manager, product owners, architects, etc. met 2 years ago, and again at EVERY program iteration since then (every 8-10-16 weeks whatever) that the enterprise level solution to the problem was “Let’s wait until Apple actually deprecates it because they NEVER do that in an unplanned/unexpected manner,” then that’s even MORE of a failure. That no one in that large group was able to provide ANY feedback or direction whatsoever? Then, that’s the entire software development organization not following software development best practices. And, the “remedy” of Apple being more clear about deprecation wouldn’t help that team one bit. If Apple communicated the PRECISE day and hour it would be deprecated, there is functionally no way such an organization would would be able to meet any future deadline, reasonable or not.

Apple communicating about deprecation more clearly (than they already are) would ONLY help developers/organizations that are already severely lacking in the area of software development and planning. Everyone else took care of this a LOONG time ago, probably prior to last year’s major OS release. And, thanks to Apple, these ineffective teams will finally be able to get it done prior to THIS year’s major OS release.

 

[chucker23n1]

the enterprise level solution to the problem was “Let’s wait until Apple actually deprecates it”

Yup. Not to mention Python itself stopped providing security updates two years ago.

 

[Unregistered 4U]

The WHY is not "why is Apple removing Python 2", it is "Why are they removing Python 2 in a dot release? Why not either w/ macOS 12.0 or 13.0?"
I can't believe I have to spell out such an obvious point, but that's the internet for you.

They’re removing it in a dot release because it literally doesn’t matter to anyone that’s been paying even partial attention to what’s going on with macOS and Python for the last 10-14 years or so. To those that WEREN’T paying attention, yeah, this will be some pain for them. BUT, managing technical debt is probably a development best practice that this will help underscore the importance of. Thanks Apple!

 

[WeatherWeasel]

I am using Weathercat which of late has been crashing and saying I need to upload Python 3. I am thinking of parting ways of that app . If Apple is not going to include Python 3 in future uploads, I went and looked. yeah, only 105 hours to upload. WTF? so perhaps if Apple is not going to use it, why do I need it? Oh heck the weathers software website is frequently down for whatever reason. Should I wait to see what apple does in future updates?

 

[adrianlondon]

Python 3 can be downloaded (on my internet) in 15-20 seconds.

Python Release Python 3.10.4

The official home of the Python Programming Language

www.python.org

 

[WeatherWeasel]

Python 3 can be downloaded (on my internet) in 15-20 seconds.

Python Release Python 3.10.4

The official home of the Python Programming Language

www.python.org

Thank you.

 

[GarryB]

I am using Weathercat which of late has been crashing and saying I need to upload Python 3. I am thinking of parting ways of that app . If Apple is not going to include Python 3 in future uploads, I went and looked. yeah, only 105 hours to upload. WTF? so perhaps if Apple is not going to use it, why do I need it? Oh heck the weathers software website is frequently down for whatever reason. Should I wait to see what apple does in future updates?

I'd be a bit wary of Weathercat. Apple have told developers they should include a Python3 runtime with their apps. They should not require you to download the Command Line Tools [it's not clear whether you are downloading the Python tools or the tools that are part of Xcode]. A Python runtime should only add 10MB or so.

Apple will not change their approach – they will not provide Python3 wth macOS. Also, you can download from python.org but, most of the packages I've seen also come with a full IDE and other tools which you will not need for apps like Weathercat. I expect that over time more developers will embed a Python runtime. This has the benefit of ensuring that the correct version of Python is used with their apps.

 

[Notfroggy]

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.


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.

I really don't have sympathy. Python 3 was first released 14 years ago. We're not talking about something that's cropped up last week. And I guess since, gosh, you already though of that, you should have dealt with it. Finally, since you seem to be operating in a professional environment, it's your responsibility to understand the risks you're running and either accept, mitigate or deal with the panic/fire fighting when those risks are realised - not moan at people who point out the obvious.

 

[theluggage]

Python 3 was first released 14 years ago. We're not talking about something that's cropped up last week.

Sure, you can just ignore the long, sad history of why the transition from Python 2 to Python 3 was a complete dumpster fire that led to Python 2 being supported until 2020 and major problems with dependencies....

But I'm not sure why you're ignoring the actual point that people have been trying to make - which isn't that Python 2 should have stayed in MacOS for ever, but that it's just plain bad practice to suddenly remove functionality - even obsolete functionality - on a point release of an OS. The end of Python 2 support shouldn't have been news to Apple either and they've had 2-3 opportunities to remove it as part of a major release, when developers and serious users expect things to break and can plan to extensively test their software and weed out abandonware.

 

[chucker23n1]

But I'm not sure why you're ignoring the actual point that people have been trying to make - which isn't that Python 2 should have stayed in MacOS for ever, but that it's just plain bad practice to suddenly remove functionality - even obsolete functionality - on a point release of an OS.

The "suddenly" part isn't entirely true, though. Apple had announced the impending removal in June 2019.

I agree that they shouldn't have removed it in a minor release (it's not a point release), but I don't agree with "sudden". They gave two and a half years' time!

 

[adrianlondon]

They removed Python 2? I'll have to port all my apps to Flash.

 

[CarlJ]

They removed Python 2? I'll have to port all my apps to Flash.

Nah, rewrite everything in Fortran.

The whole last part of this thread sounds like, "well, sure, they told me the ship was sinking and to abandon ship posthaste, but I'm upset because they didn't announce it again right before the last bit of the ship slipped beneath the waves - this is terribly inconvenient to me."

Apple announced Python 2 would go away, everyone should have started moving to the lifeboats then, not wait until your feet start getting wet (and then complain about insufficient warning).

If one "really needs Python 2", then install it via HomeBrew or similar. If you can't be bothered to do that, then I'll question your definition of "really needs Python 2".

 

[chucker23n1]

I think the "why did they do it in a minor release" criticism is valid. Likewise, why pick 12.3 to remove nano?

It makes sense for IT departments to give a major upgrade more scrutiny. If not, why even bother calling them minor updates?

 

[Unregistered 4U]

I think the "why did they do it in a minor release" criticism is valid. Likewise, why pick 12.3 to remove nano?

It makes sense for IT departments to give a major upgrade more scrutiny. If not, why even bother calling them minor updates?

Does Apple refer to them as minor? Anyway, I still see the criticism as invalid mainly because one has to intentionally make a large number of consecutive bad decisions to put themselves into the position where this would be a problem. If someone bashes themselves in the head with a hammer, I wouldn’t criticize the company that made hammers out of metal hard enough to damage a head.

 

[chucker23n1]

Does Apple refer to them as minor?

Their nomenclature seems to be major, minor, patch.

(macOS 10.x is arguably a special case. Technically, 10.1 Puma, …, 10.5 Leopard, …, 10.10 Yosemite, etc. were "minor", but that clearly wasn't the intended message.

But, with macOS 12.x, 12.0 is the major release. 12.1, 12.2 and 12.3 are clearly minor.)