| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
Is PyInterpreterState_SetEvalFrameFunc() really usable in the semi-stable API? The second parameter type comes from the internal C API. There is nothing to inspect a _PyInterpreterFrame structure in the semi-stable API.
I don't know how debuggers use PyInterpreterState_SetEvalFrameFunc().
cc @markshannon
Sorry, something went wrong.
There was a problem hiding this comment.
Some comments from taking a look out of curiosity
Sorry, something went wrong.
| There are two tiers of API with different stability exepectations, | ||
| enabled by specific macros: | ||
|
|
||
| - :c:macro:`Py_USING_SEMI_STABLE_API` exposes API that may change | ||
| without deprecation warnings. | ||
| - :c:macro:`Py_LIMITED_API` exposes API that is compatible across | ||
| several minor releases. |
There was a problem hiding this comment.
exepectations -> expectations
One could also say: "there are two public tiers of the API" (emphasis just to show addition); underscored resp. Py_BUILD_CORE are arguably a tier as well...?
I've struck out the "two" because I think it would be clearer to expose the full hierarchy, à la:
| There are two tiers of API with different stability exepectations, | |
| enabled by specific macros: | |
| - :c:macro:`Py_USING_SEMI_STABLE_API` exposes API that may change | |
| without deprecation warnings. | |
| - :c:macro:`Py_LIMITED_API` exposes API that is compatible across | |
| several minor releases. | |
| There are three public tiers of the API with different stability | |
| expectations, two of which need to be enabled by specific macros: | |
| - :c:macro:`Py_LIMITED_API` exposes API that is compatible across | |
| several minor releases. | |
| - (no macro): default C-API covered by :pep:`387`. | |
| - :c:macro:`Py_USING_SEMI_STABLE_API` exposes API that may change | |
| without deprecation warnings between minor releases. |
I'd also suggest to lead with the most stable one.
Sorry, something went wrong.
There was a problem hiding this comment.
By “There are two tiers of API with different stability expectations” I wanted to present them as being additional, different from the default that's covered in the preceding paragraphs.
The order matches the detailed sections below, which would be somewhat tricky to reorder -- the one-paragraph semi-stable tier would feel lost if it was at the end.
Sorry, something went wrong.
| use :c:func:`PyCode_NewEmpty` instead. | ||
|
|
||
| Since the definition of the bytecode changes often, calling | ||
| :c:func:`PyCode_New` directly can bind you to a precise Python version. |
There was a problem hiding this comment.
style: better "can directly" than "directly can" (or directly at the very end)
Sorry, something went wrong.
There was a problem hiding this comment.
It's not “can directly bind you”, but “calling :c:func:PyCode_New directly” (as opposed to PyCode_Replace for example)
Sorry, something went wrong.
| @@ -0,0 +1,10 @@ | |||
| Defining :c:macro:`Py_USING_SEMI_STABLE_API` will expose "semi-stable API", | |||
There was a problem hiding this comment.
Perhaps it's worth considering to stay consistent with the spelling of "semi-stable" / "semistable". Currently the include folders are named like the latter (which I think looks good in a path), mentions in the docs like here often have the hyphen.
Even though the hyphen is grammatically slightly more correct, my personal preference would be without.
Sorry, something went wrong.
There was a problem hiding this comment.
Which also opens the question if the macro should be Py_USING_SEMI_STABLE_API or Py_USING_SEMISTABLE_API
Sorry, something went wrong.
There was a problem hiding this comment.
I still have hope that someone will come up with a better name. Python-dev is usually so good at bikeshedding!
I'll postpone renaming for now.
Sorry, something went wrong.
|
Thank you for the comments! |
Sorry, something went wrong.
There was a problem hiding this comment.
I expected the API and macro to mention "unstable" rather than "semi-stable" (Py_USING_SEMI_STABLE_API => Py_USING_UNSTABLE_API).
Sorry, something went wrong.
| PyObject *, PyObject *, PyObject *, int, PyObject *, | ||
| PyObject *); | ||
| /* same as struct above */ | ||
| /* See Include/semi-stable/code.h for PyCode_New* */ |
There was a problem hiding this comment.
I'm not sure that this comment is useful.
| /* See Include/semi-stable/code.h for PyCode_New* */ | |
| /* See Include/unstable/code.h for PyCode_New* */ |
Sorry, something went wrong.
|
|
||
| // Expose unstable API when building Python | ||
| #ifdef Py_BUILD_CORE | ||
| #define Py_USING_UNSTABLE_API |
There was a problem hiding this comment.
| #define Py_USING_UNSTABLE_API | |
| # define Py_USING_UNSTABLE_API |
Sorry, something went wrong.
| #ifdef Py_USING_UNSTABLE_API | ||
| #define _Py_NEWLY_UNSTABLE(VERSION_UNUSED) | ||
| #else | ||
| #define _Py_NEWLY_UNSTABLE(VERSION) Py_DEPRECATED(VERSION) | ||
| #endif |
There was a problem hiding this comment.
| #ifdef Py_USING_UNSTABLE_API | |
| #define _Py_NEWLY_UNSTABLE(VERSION_UNUSED) | |
| #else | |
| #define _Py_NEWLY_UNSTABLE(VERSION) Py_DEPRECATED(VERSION) | |
| #endif | |
| #ifdef Py_USING_UNSTABLE_API | |
| # define _Py_NEWLY_UNSTABLE(VERSION_UNUSED) | |
| #else | |
| # define _Py_NEWLY_UNSTABLE(VERSION) Py_DEPRECATED(VERSION) | |
| #endif |
Sorry, something went wrong.
| PyObject *, PyObject *, PyObject *, PyObject *, | ||
| PyObject *, PyObject *, PyObject *, int, PyObject *, | ||
| PyObject *); | ||
| /* same as struct PyCodeObject */ |
There was a problem hiding this comment.
I suggest to move the comment before the function definition: "same parameters as PyCodeObject structure members".
Sorry, something went wrong.
|
|
||
| /* Frame evaluation API (added for PEP-523) */ | ||
|
|
||
| struct _PyInterpreterFrame; |
There was a problem hiding this comment.
Is this needed?
Sorry, something went wrong.
|
|
||
| - :c:macro:`Py_USING_SEMI_STABLE_API` exposes API that may change | ||
| without deprecation warnings. | ||
| - :c:macro:`Py_LIMITED_API` limits exposed API to API that is compatible |
There was a problem hiding this comment.
Is API repeated on purpose?
| - :c:macro:`Py_LIMITED_API` limits exposed API to API that is compatible | |
| - :c:macro:`Py_LIMITED_API` limits exposed API that is compatible |
Sorry, something went wrong.
|
|
||
| #define Py_UNSTABLE_CODE_H | ||
| #include "unstable/code.h" | ||
| #undef Py_UNSTABLE_CODE_H |
There was a problem hiding this comment.
I would prefer to include it in top-level Include/code.h, as done in Include/pystate.h.
Sorry, something went wrong.
| - :c:func:`PyInterpreterState_GetEvalFrameFunc` | ||
| - :c:func:`PyInterpreterState_SetEvalFrameFunc` | ||
| - :c:type:`PyFrameEvalFunction` | ||
|
|
There was a problem hiding this comment.
Maybe mention also _PyFrameEvalFunction type which is renamed?
Sorry, something went wrong.
|
I'm deferring the PEP. Thanks for the comments, I'll take them into account next time I try. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This adds the semi-stable API tier witth a few initial functions/types. Adding more is left to another PR.