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

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, _Py_Dealloc is used by Py_DECREF.

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