From a6913ed7f35fcfb80e5e2b41b4caabcc9cb6c9d2 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Mon, 5 Sep 2016 14:54:41 -0700 Subject: [PATCH] Make all frame evaluation API changes private to start (#93) --- pep-0523.txt | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/pep-0523.txt b/pep-0523.txt index d7d9baa70..5c179c2e1 100644 --- a/pep-0523.txt +++ b/pep-0523.txt @@ -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.