Hi Guido,
It seems like you are talking about the Python API.
Primarily, yes.
In the C API, there is the internal C API which fits with your
description. To access it, you have to declare the
Py_BUILD_CORE_MODULE macro. It's not usable directly on purpose. It's
an user agreement: I know what I am doing, and I know that this API is
not supported nor stable.
Hm, but aren't for example all the fields of code objects (co_name, co_argcount, etc.) in the "non-internal" API? Those (and the functions that manipulate code objects) are a prime example of what I'd consider "unstable".
On
https://docs.python.org/3/c-api/code.html it already says about the fields "The
fields of this type are subject to change at any time." But I think everything else on that page should be considered unstable as well. (And why do we even have
PyCode_GetNumFree()?)
I don't know if there would be a way to advertise that a Python API is
unstable. Some projects use an underscore prefix in their module names
to mark them as "private". For example, sub-modules of a package are
called "_something.py" and they exposed in package/__init__.py (or
another public module).
I was primarily thinking of the docs.