2016-09-12 8:23 GMT+02:00 Benjamin Peterson <benja...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
