Apple supported Python 2 for two years after it was officially sunset by the Python Foundation. They've been advising that they will drop support for longer.

How long is long enough to avoid breaking something the users depend on? One more year? Five years? Fifty? I think we can all agree that it's reasonable to drop support at some point, making it just a question of when and at what cost.

"How long is long enough to avoid breaking something the users depend on?"

10 years - a piece of software compiled with 'supported' libraries, SDKs and what have you should function for 10 years. An appliance or a service should function for 10 years and have spare parts avaliable for that long.

That is the guideline I ise as a consumer, if I can see that something won't last a decade, I won't be spending money or time on it if i can avoid it. At that point it's no longer a durable good, it's a consumable.

Python2.7 was supposed to be EOL in 2015(!). It was released in 2010. It had 10 years of support mainline.

There would still be Python 2.7 software being produced up to EOL, so you have to start counting from 2015.

Again, the issue is "when", not "whether".

They could drop it with v12, or wait for v13, both would be fine. Dropping it in the middle of release cycle what people are objecting to.

Apple isn't in the business of spending excess money to avoid breaking things. If anything apple is the opposite.

If there are users that still depend on python 2.7, they can install it manually?

I mean I already think it's... interesting that an operating system comes with (multiple) programming language interpreters, available to the end-user.

That’s true if they’re using it from the command-line, but not if they’re using apps that linked against the system SDK’s libpython2.7.dylib (and assumed PyObjC would be present)

Is there any significant software still using that?

Apple is pretty aggressive about breaking backwards compatibility, as they did with x86, so it's no real surprise for unmaintained software to become completely unusable.

Based on what they’ve done, I guess the answer is no.

My company was shipping (somewhat niche) software linking with the built-in python2 up until last year though, and it’s been a scramble since Monterey to rebuild things to avoid the warning message. Definitely thought we would have python2 until 13.0 though (and part of me wonders whether this is just a “brown-out” for the beta and 12.3 release will be back to normal)

Notably, however, Apple didn't drop x86 support in a minor update.

And kept the support present for I think a year and a half alongside a runtime warning message (and removed SDK support earlier than that)

> programming language interpreters, available to the end-user.

Yeah, fuck those end-users who might want to automate things with a script.

I think an end user that wants to automate things with a script can be expected to install their interpreters themselves or use an interpreter that builds on the OS's shell.

I am not to familiar with MacOS, but I imagine it comes with a bash/sh terminal? If so, then that is something that should be first choice for automation.

Everything else, be it python, perl, ruby or whatever should be installed by a user as needed.

What do you think “the OS’s shell” is?

And I think that's totally reasonable—as long as Apple makes the change in a major update, when users can expect (some) things to break and should be encouraged to make time to prepare.

Part of it is that it's just a mental burden to keep this kind of compatibility information in my brain. I have VMs set up of past macOS releases in case I need to run something old. I don't have VMs set up for earlier versions of a release, and I don't even know where I'd get an installer. Admittedly, in this case it would just be a matter of installing Python, but I don't necessarily know that as a user, or the software could need to be linked to Cocoa or some such.

That's what Windows is for.