On Thu, Apr 7, 2022 at 12:02 PM Petr Viktorin <encu...@gmail.com> 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".
> - 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.
> 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().
Should we deprecate types.CodeType constructor in the Python API,
since types.CodeType.replace() exists and seems to be a better API
("more stable")?
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/Q6W6G4DNC4JB4YWRCEY32RWZHIAKJSU5/
Code of Conduct: http://python.org/psf/codeofconduct/
