iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Make all frame evaluation API changes private to start (#93)

This commit is contained in:
Brett Cannon 2016-09-05 14:54:41 -07:00 committed by GitHub
parent 82a566fcc1
commit a6913ed7f3
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
pep-0523.txt
View File

@ -132,27 +132,27 @@ Expanding ``PyInterpreterState``
The entrypoint for the frame evaluation function is per-interpreter::
// Same type signature as PyEval_EvalFrameEx().
typedef PyObject* (__stdcall *PyFrameEvalFunction)(PyFrameObject*, int);
typedef PyObject* (*_PyFrameEvalFunction)(PyFrameObject*, int);
typedef struct {
...
PyFrameEvalFunction eval_frame;
_PyFrameEvalFunction eval_frame;
} PyInterpreterState;
By default, the ``eval_frame`` field will be initialized to a function
pointer that represents what ``PyEval_EvalFrameEx()`` currently is
(called ``PyEval_EvalFrameDefault()``, discussed later in this PEP).
(called ``_PyEval_EvalFrameDefault()``, discussed later in this PEP).
Third-party code may then set their own frame evaluation function
instead to control the execution of Python code. A pointer comparison
can be used to detect if the field is set to
``PyEval_EvalFrameDefault()`` and thus has not been mutated yet.
``_PyEval_EvalFrameDefault()`` and thus has not been mutated yet.
Changes to ``Python/ceval.c``
-----------------------------
``PyEval_EvalFrameEx()`` [#pyeval_evalframeex]_ as it currently stands
will be renamed to ``PyEval_EvalFrameDefault()``. The new
will be renamed to ``_PyEval_EvalFrameDefault()``. The new
``PyEval_EvalFrameEx()`` will then become::
PyObject *
@ -233,7 +233,7 @@ The frame evaluation function has (roughly) the following algorithm::
else:
pyjion_code.jit_failed = True
pyjion_code.exec_count += 1
return PyEval_EvalFrameDefault(frame, throw_flag)
return _PyEval_EvalFrameDefault(frame, throw_flag)
The key point, though, is that all of this work and logic is separate
from CPython and yet with the proposed API changes it is able to
@ -297,7 +297,7 @@ Allow ``eval_frame`` to be ``NULL``
Currently the frame evaluation function is expected to always be set.
It could very easily simply default to ``NULL`` instead which would
signal to use ``PyEval_EvalFrameDefault()``. The current proposal of
signal to use ``_PyEval_EvalFrameDefault()``. The current proposal of
not special-casing the field seemed the most straightforward, but it
does require that the field not accidentally be cleared, else a crash
may occur.