STINNER Victor <vstin...@python.org> added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue42990>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
