Hi Guido, It seems like you are talking about the Python API. 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. 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). Victor On Thu, Jun 3, 2021 at 7:14 PM Guido van Rossum <guido@python.org> wrote:
This is not a complete thought yet, but it occurred to me that while we have deprecated APIs (which will eventually go away), and provisional APIs (which must mature a little before they're declared stable), and stable APIs (which everyone can rely on), it might be good to also have something like *unstable* APIs, which will continually change without ever going away or stabilizing. Examples would be the ast module (since the AST structure changes every time the grammar changes) and anything to do with code objects and bytecode (since we sometimes think of better ways to execute Python).
So maybe the docs should grow a standard way of saying "this is an unstable API"?
Would we need a PEP to create an initial list of APIs (modules, classes, etc.) that are considered unstable?
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/JM6SQ2YN... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.