Tuples should be immutable and safe in C, as well as in Python.

Bug report

Bug description:

[Apologies if this sounds a bit like a rant. I'm not blaming anyone. Just because something is the wrong choice now, doesn't mean it wasn't the right choice historically]

Tuples are immutable in Python, but we play all sorts of games in C with tuples, filling them will NULLs, mutating them and reusing them.

We do this in the mistaken belief that it improves performance.
But it doesn't. It makes the code base more complicated and fragile as we need to work around tuples that misbehave and do strange things. Any local performance gain is overwhelmed by slowdowns caused by the extra complexity in tuple code, the garbage collector and a few other places.

So let's fix this.

We need to:

• Provide a new C API PyTuple_MakePair(). Pairs are by far the most common type of tuple that we play games with. By providing a fast way to create pairs, we can provide an upgrade path for C code that creates tuples in unsafe ways to do so safely and quickly.
• Deprecate PyTuple_New. I don't know when we'll be able to remove it, but we should deprecate it ASAP.
• Change PyTuple_New to fill the tuple with pointers to None instead of NULL. This doesn't fix the mutability issue, but it at least means the GC will only see valid objects. (This might break too much code, so we might just have to clearly document that tuples should be fully initialized in one go, before the tuple escapes the function it was created in)
• Fix our own code to not use PyTuple_New() or perform tuple shenanigans. We can't reasonably expect third-party package authors to follow the rules if we don't.

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

• gh-127758

Beginne damit, die C APIs PyTuple_New und PyTuple_MakePair zu prüfen, und sieh dir anschließend den verknüpften PR gh-127758 an, um die bereits laufenden Arbeiten zu verstehen. Als abgeschlossen gilt die Umsetzung der angeforderten Änderungen zur Tupelsicherheit, einschließlich des API-Übergangs, des Initialisierungsverhaltens und der Entfernung unsicherer interner Tupelverwendung.