On Mon, Jun 13, 2022 at 4:18 PM Petr Viktorin <encukou@gmail.com> wrote:
- We won't break this internal API for no reason, so if you use it now and have good tests you don't need stop using it right now.
I disagree with that. We don't provide any backward compatibiltiy warranty for reasons. They are bugfixes which require changing internal API: add parameter, change the behavior, remove a function, etc. In the past, all bug reports about changed internal API used by 3rd party modules was rejected.
If you want to start providing backward compatibility warranty, you should put it in your "unstable API" bag or create a documented and test public API instead.
_PyCode_GetExtrais mentioned in PEP 523, but not documented on docs.python.org. As a user, can I use it?
I would say: no, don't use it :-) Or in general, you can use a private function, but in that case, *you are on your own*, don't expect support from Python core developers, nor backward compatibility warranties.
_PyImport_AcquireLockis mentioned in a StackOverflow answer, but not on docs.python.org. As a user, can I use it?
Nope :-) Don't use it.
If there are reasons to call this function, it should become a public function instead.
But importlib changed a lot last years, I'm not sure that it's still needed.
- I find that (say)
_PyArg_UnpackStackis no longer necessary in CPython. As a core dev, where do I need to look to see if I can remove it?
This function should be move to the internal C API. I already tried, but it requires to modify Argument Clinic to add an include "pycore_modsupport.h". Modifying Argument Clinic is not easy, so I gave up on that one for now.
The issues these point out can't be fixed easily: there are hundreds of underscored functions exposed in the public headers, and no good way to prevent adding new ones (of either kind -- consumable or private).
We can add a tool check list names in the public C API, allow existing names prefixed by "_Py" but disallow add new ones (unless you explicitly allow these new names).
Some API is even only exposed for technical reasons:
_Py_NewRefneeds to be exposed, even though we'd like users to never use it. (This particular function is not too dangerous to use, but any macro orstatic inlinefunction that's an implementation detail has the same issue.)
This one is only there for performance. We should not bother about micro-optimization and just remove the static inline implementation and always use the regular function call instead.
Victor
Night gathers, and now my watch begins. It shall not end until my death.