[Python-Dev] Python 3.7: remove all private C functions from the Python C API? (original) (raw)

Victor Stinner victor.stinner at gmail.com
Mon Sep 12 04:41:52 EDT 2016

2016-09-12 8:23 GMT+02:00 Benjamin Peterson <benjamin at python.org>:

That seems like a good idea in abstract. However, the boundaries will have to be delineated. Many functions beginning Py are effectively part of the public API even for "well-behaved" 3rd-party extensions

Oh ok, that's also what I expected.

So we should be very careful. Maybe we can experiment building a few major C extensions like numpy to find such issues?

I already know that some C extensions have to access low-level internals, like debuggers or profilers. Maybe we need to add something to allow these extensions being compiled with the "private API"?

because they are used by magic macros. For example, PyDealloc is used by PyDECREF.

I suggest to make _Py_Dealloc() public, but explain in its documentation that you should not use it directly :-)

In some cases, we should define a function for the public API/ABI, but use a macro for the Python core. We already do that in some cases. Example:

PyAPI_FUNC(PyThreadState *) PyThreadState_Get(void);

#ifdef Py_BUILD_CORE PyAPI_DATA(_Py_atomic_address) _PyThreadState_Current; # define PyThreadState_GET()
((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current)) #else # define PyThreadState_GET() PyThreadState_Get() #endif

For Py_DECREF, I prefer to keep a macro because this one is performance critical.

Victor

More information about the Python-Dev mailing list