STINNER Victor <vstin...@python.org> added the comment:
Maybe a PEP is needed to collect usages of the Py_buffer API and check if the ABI is future proof. A PEP may help to discuss with other projects which currently consume this API. I suggest to start with the smallest possible API and then slowly extend it. It's too easy to make mistakes :-( Once it's added to the stable ABI, it will be really hard to change it. For example, PyBuffer.format is a "char*", but who owns the string? For a stable ABI, I would suggest to duplicate the string. For shape, stripes and suboffsets arrays, I would also suggest to allocate these arrays on the heap people to ensure that it cannot be modified from the outside. In your PR, PyBuffer_GetLayout() gives indirectly access to the internal Py_buffer structure members and allows to modify them. One way is to avoid this issue is to return a *copy* of these arrays. I would prefer to require to call "Set" functions to modify a Py_buffer to ensure that a buffer always remains consistency. > PyBuffer_NewEx(PyObject *obj, void *buf, Py_ssize_t len, Py_ssize_t > itemsize, int readonly, int ndim, char *format, Py_ssize_t *shape, Py_ssize_t > *strides, Py_ssize_t *suboffsets, void *internal) This API looks like PyCode_New() which was broken *often* so it looks like a bad pattern for a stable ABI. Maybe PyBuffer_New() + many Set() functions would be more future proof. But I don't know which Py_buffer members are mandatory to have a "valid" buffer. What if tomorrow we add new members. Will it be possible to initalize them to a reasonable default value? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45459> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
