PyObject *
_PyEval_EvalCode(PyThreadState *tstate,
           PyObject *_co, PyObject *globals, PyObject *locals,
           PyObject *const *args, Py_ssize_t argcount,
           PyObject *const *kwnames, PyObject *const *kwargs,
           Py_ssize_t kwcount, int kwstep,
           PyObject *const *defs, Py_ssize_t defcount,
           PyObject *kwdefs, PyObject *closure,
           PyObject *name, PyObject *qualname)

Hum no, only 16 arguments, everything is fine! :-D

More seriously, I already considered to rework this code.

The pseudo code is:

  if (...) return <new generator>;
  frame = (...);
  retval = _PyEval_EvalFrame(tstate, f, 0);
  _PyObject_GC_TRACK(f);
  return retval;

I like the idea of splitting these two parts:

  f = create_frame_or_gen(...);
  if (<is generator>) return f;
  retval = _PyEval_EvalFrame(tstate, f, 0);
  _PyObject_GC_TRACK(f);
  return retval;

I see one advantage: stack memory consumation, we don't have to hold the 16 arguments on the stack, only 3 parameters (tstate, f, 0).

> Split the Eval functions into vector and tuple/dict forms, both forms taking a "frame descriptor", as well as the arguments.

Hum, it seems like you have a different idea how to refactor the code.

Would it be worth it to have more specialized create_frame_or_gen() functions for the common cases?

--

I would also be interested by the ability to not create a frame at all, but I guess that it's a way larger refactoring.