I would like to get the testing infrastructure for 3.15 up before adding 3.15 branches. It also doesn't fill me with confidence that we already have stubtest errors without even testing 3.15.

Here's my suggestion on how to move forward:

1. Get the testing infrastructure in place. We'll need to add many stubtest allow entries as a "to do list" to the 3.15 allow lists. (Like we had in the past.)
2. Split this PR into multiple PRs with a size that's easily reviewable.
3. Fix remaining issues per PR, but move "harder" fixes to separate PRs if necessary.
4. Review each PR manually for plausibility and style. When looking at the existing PR, it's clear to me that on the one hand the LLM managed to do a lot of the "grunt work" and provide a good baseline, but on the other hand delivered results that are not suitable for unsupervised inclusion in typeshed.

Hi! There's one new addition in 3.15 which I notice is missing from the release notes and the current PR:
python/cpython#140951
https://docs.python.org/3.15/library/wave.html#wave.open.

I guess if the What's New is up to date there shouldn't be a problem for the AI but maybe there are other changes also missing?

wave.open: Yes, I had it look only at the What's New. I think we're liable to miss such changes to only allowed parameter types, because there's no automatic way to check them; I wouldn't be surprised if we similarly missed some changes for earlier versions. Maybe I'll try making an AI look at the whole diff between 3.14 and 3.15 and flag things that were missed.

Point taken on getting CI set up first, I'll do that.

The stubtest failures seem to be mostly from changes that were made unconditionally that should have been made conditional on version.

My plan now:

• Add 3.15 CI (Add Python 3.15 test infrastructure #15718)
• Make Codex fix all CI issues on this PR to have a clean slate (in progress)
• Extract separate PRs for smaller changes (probably <5 modules at a time); start them as draft and request review when I feel they're ready.

Extract separate PRs for smaller changes (probably <5 modules at a time); start them as draft and request review when I feel they're ready.

I'll try to prioritize reviewing. If it's just small, straight-forward changes, I'm fine with larger PRs. It's more about the amount if lines and the complexity than the amount of modules.

With lots of other PRs merged, this is now mostly allowlist sorting.

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉