gh-145098: Run Apple Silicon macOS CI on macos-26 (Tahoe)

[clintonsteiner]

• Issue: CI: move Apple Silicon macOS workflows to macos-26 (Tahoe) #145098

[hugovk]

I'm curious if there's any performance difference between this and the previous one, can you compare times?

Also noting this image is still in beta but should be GA "around November" [2025], "before Xcode 26.3 releases" [20 Feb], "late February / early March, but depends on Xcode 26.4 behavior in general, so no promises".

actions/runner-images#13008

I don't see this as a blocker as long as everything we need is in there.

[hugovk]

We don't need a NEWS file for CI changes, please can you remove it?

[clintonsteiner]

Removed @hugovk seeing around 2.5 mins slower on pr run... I'm shocked, and didn't se this wasn't ga yet, just saw it using old mac os and since I had just tested on tahoe, figured the ci should match.

Thanks for the review! Removed news posting

[hugovk]

Job	macos-14 (main)	macos-26 (PR)	Diff
build and test	8m 39s	12m 11s	+3m 32s (+41%)
free-threading build and test	15m 58s	18m 25s	+2m 27s (+15%)
Android (aarch64)	4m 09s	3m 34s	-35s (-14%)
iOS	16m 29s	21m 34s	+5m 05s (+31%)
JIT aarch64 (Debug)	15m 43s	15m 04s	-39s (-4%)
JIT aarch64 (Release)	15m 36s	13m 09s	-2m 27s (-16%)
tail-call aarch64	9m 54s	9m 45s	-9s (-2%)

[webknjaz]

Bumping the OS seems fine, although the downloader refactoring feels standalone..

[freakboy3742]

My concern is less about speed, and more about reliability.

For background - there is no issue running CPython on macOS-26. This is entirely a GitHub Actions issue.

The macOS-15 runner has proven to be massively unreliable, and I haven't seen any movement on actions/runner-images#12777 or actions/runner-images#13275/actions/runner-images#13459 that suggests those issues have been fixed.

Before this lands, I'd want to see a dozen or so re-runs to give some confidence that the simulator boot reliability issues we've seen on macOS-15 have been resolved on macOS-26.

I also share the concern about conflating the downloading change with the CI change - is there a direct connection with the macOS runner here? The comment about "some runner/proxy setups" suggests it might be... but it's not clear if this is only to address an issue you've seen locally.

[clintonsteiner]

I changed the download run probably due to unreliability of the runner, failed downloads twice and didn't know if it was a regression in the os of the runner's curl capability @freakboy3742

[freakboy3742]

I changed the download run probably due to unreliability of the runner, failed downloads twice and didn't know if it was a regression in the os of the runner's curl capability @freakboy3742

GitHub Actions failing downloads is a fairly common, but entirely inconsistent phenomenon. I've seen errors from GitHub accessing GitHub downloads. Unless you have concrete evidence that the issue is HTTP 1.1 compliance, I'd rather not complicate that section of code (or at least defer it to a separate PR, where we can address the same issue on other platforms like Android and Emscripten).

[clintonsteiner]

@freakboy3742 agreed, I had just pushed a revert a minute ago actually

[hugovk]

@clintonsteiner Please can you resolve the conflict in jit.yml?

And revert the unrelated changes to Include/internal/pycore_dict.h and Objects/dictobject.c?

27b3fa0