On 2019-02-28, Antoine Pitrou wrote:
Le 28/02/2019 à 20:09, Neil Schemenauer a écrit :
The PyObject structure could be:
typedef struct { size_t refcnt; pyref_t *r; } PyObject;Are you showing the PyPy implementation of PyObject?
Yes, this is an example of what PyPy would allocate when you create a PyObject from a pyref. In this case, it is an example of what gets allocated if you have the opaque PyObject flag turned on. The non-opaque version would need to have a compatible structure layout, e.g. something like:
typedef struct { ssize_t ob_refcnt; PyObject *ob_type; pyref_t *r; } PyObject;
To solve the non-opaque PyObject/PyTypeObject issue, I think you could have a source code option that turns on opaque types.
I don't understand what this means. Do you need a special CPython build with a different set of preprocessor options? Or is this when building an extension?
It is a source option for the extension. You don't need a special CPython build. The extension module source code would turn on the opaque types before included the Python API headers, e.g.
#define Py_OPAQUE_PYOBJECT 1
#include <Python.h>(if the latter, it sounds close to the existing "stable ABI")
I guess they are similar. As I understand, if the limited API is turned on, PyTypeObject becomes opaque but PyObject is not. My Py_OPAQUE_PYOBJECT would also make PyObject opaque. I suppose that's not a big difference because PyObject is actually not too hard to make opaque, PyTypeObject is the tricky one.
If we are overhauling the API, I think there should be a separate option to toggle ABI stability. If you turn it off, functions can become inlined. As an extension author, I can use just use PyList_GetSize(o). The person compiling the extension can decide they would rather get those small functions inlined and lose the ABI stability. If you are distributing a pre-built extension on PyPI, you probably want the ABI stability flag on (and pay the performance hit).
Regards,
Neil