Does this add much extra CPU/stack/memory overhead for calling Python from C? Or alternating py/c/py/c/py calls? Probably not the most important use-cases, but I would hope that they wouldn't pessimize too much.

Does this add much extra CPU/stack/memory overhead for calling Python from C?

• CPU: A little, but it speeds up the return sequence. The net effect is about zero
• C Stack consumption is increased, but only 80 bytes per call.

The performance impact of this negative but I want to merge anyway because:

• The more negative benchmarks seem to use generators a fair bit, e.g https://github.com/python/pyperformance/blob/main/pyperformance/data-files/benchmarks/bm_nqueens/run_benchmark.py#L27 This PR is an enabler of optimizing entering and exiting generators and coroutines, so we would expect a win in the longer term on those benchmarks.
• I expect further benefits from this change once GH-91095: Specialize calls to normal python classes #93221 is merged.
• In the long term we expect calls to _PyEval_EvalFrameDefault() to become rare, as we move more control into bytecode.

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

I have made the requested changes; please review again

Thanks for making the requested changes!

@brandtbucher: please review the changes made to this pull request.

I don't know if I'll have time to review again today (still need to prepare my talk for the release stream). Is this able to wait until next week? If not, I can try to make time.

It can wait until next week