Is the only difference betweenRETURN_VALUE_FUNC andRETURN_VALUE_GEN the call to_PyEval_ClearThreadFrame vs_PyEval_ClearGenFrame? Couldn't_PyEval_FrameClearAndPop just switch on whether or notframe->owner == FRAME_OWNED_BY_GENERATOR?

That's exact what it used to do.

We generally want to make decisions at compile time if we can.
It's the second bullet in#125837 (comment)

We generally want to make decisions at compile time if we can.

We also made some efforts to reduce the number of bytecodes and the size of the eval loop implementation.
And copy-pasting 20 lines of code to change one is... controversial.

And copy-pasting 20 lines of code to change one is... controversial.

It's 16 lines, but I see your point.

Doing this gives more flexibility to refactor and optimize the two return paths separately.
Both_PyEval_ClearGenFrame and_PyEval_ClearThreadFrame call_PyFrame_ClearExceptCode() but have to do
different things around that call.

For example, we could end up with something like this:

macro(RETURN_VALUE_FUNC)=_CLEAR_FRAME+_POP_THREAD_FRAME+_RETURN_VALUE;macro(RETURN_VALUE_GEN)=_GEN_POP_EXC_STATE+_CLEAR_FRAME+_RETURN_VALUE;

but not in this PR.

Could you comment out rather than delete?

I'd rather delete it, otherwise it just rots.

We do have version control, if you need it back.

Could you comment out rather than delete?

If it doesn't get deleted, compiler may raise warnings, see325c5fe:
‘all_exits_have_lineno’ defined but not used [-Wunused-function]

If it doesn't get deleted, compiler may raise warnings

But not if it's commented out.