[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