On 07. 04. 22 17:10, Victor Stinner wrote:
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".
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.
_______________________________________________
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/MBDJH4J5SA2GJENCBWTHA53KURPX2S4J/
Code of Conduct: http://python.org/psf/codeofconduct/
