[3.11] gh-101100: Fix Py_DEBUG dangling Sphinx references (#115003)

[smontanaro]

No change to 3.11 branch for Doc/library/test.rst because the relevant section was new in 3.12.

---

📚 Documentation preview 📚: https://cpython-previews--115141.org.readthedocs.build/

• Issue: Fix all Sphinx reference warnings in the documentation #101100

[AlexWaygood]

@smontanaro, please make sure to select the correct base branch when creating backport PRs. If you try to merge a 3.11 backport PR into the main branch (what you originally did here), you end up pinging all active core developers due to how GitHub's CODEOWNERS feature works :)

[smontanaro]

@smontanaro, please make sure to select the correct base branch when creating backport PRs. If you try to merge a 3.11 backport PR into the main branch (what you originally did here), you end up pinging all active core developers due to how GitHub's CODEOWNERS feature works :)

I was on my 3.11 branch. In addition, the cherry_picker command includes the branch on the command line. I have no idea why the PR in GitHub is against the main branch. I think I'm doing everything right.

[zware]

The branch was created correctly, based on 3.11. The the PR was not, though, its base branch was main (GitHub is not aware enough to care about long-lived branches and thus choose the correct base branch on its own). How are you opening the PR? If it's cherry_picker opening it on its own (I can't remember whether it does that, it hasn't been working for me for other reasons lately :) ), it may have a bug.

[smontanaro]

The branch was created correctly, based on 3.11. The PR was not, though, its base branch was main...

Ah, that's the problem. It hadn't occurred to me that there was a choice to make at that step. I thought everything would just be correct. The first time I even tried to make a PR against anything but main was a few days ago. I clearly need to up my game in this regard. Apologies for the problem.

[terryjreedy]

This sort of splat is common enough that must of us now know to check further emails to see if someone has already handled it before even clicking to do anything. Please keep contributing.

This one was solved by re-basing and close/open to restart tests. Force-pushing sometimes results in a mess that requires closing and starting over with a new PR.

Alex, Zachary: could we ask GH to add a way to clear the reviewer request list? Or either question or refuse to create PRs like this? Or add a hook that calls our code before making the PR? EDIT Or have we tried already?

[AlexWaygood]

This sort of splat is common enough that must of us now know to check further emails to see if someone has already handled it before even clicking to do anything. Please keep contributing.

+1. Apologies if my first message was overly critical, @smontanaro :)

Alex, Zachary: could we ask GH to add a way to clear the reviewer request list? Or either question or refuse to create PRs like this? Or add a hook that calls our code before making the PR? EDIT Or have we tried already?

I recall us giving some informal feedback to GitHub some time ago that it would be nice to introduce some more friction to the PR-making process, to make this kind of thing less common. But I don't know that anything came of it; it might well be worth trying again

[smontanaro]

No worries. You didn't put me off... In fact:

https://discuss.python.org/t/dis-py-stack-append-vs-stack-push/45330