On 13. 06. 22 17:36, Marc-Andre Lemburg wrote:
In the past we always said: "_Py* is an internal API. Use at your own risk.", which I guess is somewhere between the warning and the strict "don't use" policy you are describing.
The problem with the "don't use" policy is that in some cases, there are no public APIs available to do certain things and so the extension writers have to resort to the private ones to implement their logic.
E.g. to implement a free list for Python objects, you have to use _Py_NewReference() in order to create an object based on a memory area taken from the free list. If you want to create a bytes objects using overallocation, it's common to use _PyBytes_Resize() to resize the buffer to the final size.
What sometimes happens is that after a while the private APIs get their leading underscore removed to then become public ones.
It's not just about removing the underscore: when this happens the APIs should also get documentation, tests, and some expectation of stability (e.g. that we won't go randomly adding tstate parameters to them).
This upwards migration path would be made impossible with the "don't use" policy.
Why not? I have no doubt people will use private API, no matter how explicitly we say that it can break at any time.
My proposal is making this more explicit. And yes, it's also putting some more pressure on core devs to expose proper API for use cases people have, and on people to report their use cases.