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:: The entrypoint for the frame evaluation function is per-interpreter::
// Same type signature as PyEval_EvalFrameEx(). // Same type signature as PyEval_EvalFrameEx().
typedef PyObject* (__stdcall *PyFrameEvalFunction)(PyFrameObject*, int); typedef PyObject* (*_PyFrameEvalFunction)(PyFrameObject*, int);
typedef struct { typedef struct {
... ...
PyFrameEvalFunction eval_frame; _PyFrameEvalFunction eval_frame;
} PyInterpreterState; } PyInterpreterState;
By default, the ``eval_frame`` field will be initialized to a function By default, the ``eval_frame`` field will be initialized to a function
pointer that represents what ``PyEval_EvalFrameEx()`` currently is 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 Third-party code may then set their own frame evaluation function
instead to control the execution of Python code. A pointer comparison instead to control the execution of Python code. A pointer comparison
can be used to detect if the field is set to 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`` Changes to ``Python/ceval.c``
----------------------------- -----------------------------
``PyEval_EvalFrameEx()`` [#pyeval_evalframeex]_ as it currently stands ``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:: ``PyEval_EvalFrameEx()`` will then become::
PyObject * PyObject *
@ -233,7 +233,7 @@ The frame evaluation function has (roughly) the following algorithm::
else: else:
pyjion_code.jit_failed = True pyjion_code.jit_failed = True
pyjion_code.exec_count += 1 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 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 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. Currently the frame evaluation function is expected to always be set.
It could very easily simply default to ``NULL`` instead which would 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 not special-casing the field seemed the most straightforward, but it
does require that the field not accidentally be cleared, else a crash does require that the field not accidentally be cleared, else a crash
may occur. may occur.