On 07. 04. 22 17:10, Victor Stinner wrote:
On Thu, Apr 7, 2022 at 12:02 PM Petr Viktorin
wrote: - This API stays with the regular public API (Include/cpython/), but to use it you'll need to #define Py_USING_UNSTABLE_API (name up for bikeshedding).
Since there is already something similar called "Py_LIMITED", I suggest dropping "USING_" for just: "Py_UNSTABLE_API".
But I really like the explicit “USING” :) I don't think there's too much value in these two being consistent. (Yay, bikeshedding!)
- The functions will be renamed to drop the leading underscore. The old names will be available as aliases (using #define) and may be removed whenever the API changes. (Ideally, the underscore should always mark API that's fully private with no guarantees at all.)
Should functions entering the "unstable API" be documented and tested?
For example, _PyEval_EvalFrameDefault() and _PyInterpreterState_SetEvalFrameFunc() have no test nor doc.
Yes. I'll add docs, for tests I'll at least open an issue.
This applies to:
- PyCode_New, PyCode_NewWithPosOnlyArgs
It would be nice to update Cython to define the Py_UNSTABLE_API macro before the macro is required to get the function, since Cython still uses PyCode_New().
That (for any project, not just Cython) is why I propose warnings in 3.11, before requiring the opt-in in 3.12.
Should we deprecate types.CodeType constructor in the Python API, since types.CodeType.replace() exists and seems to be a better API ("more stable")?
I don't know. But it's for a different discussion.