> Antoine Pitrou <report@bugs.python.org> wrote:
> > >    a) Make all functions and the two buffer access macros part
> > >       of the limited API again.
> > 
> > Hmm, I don't think buffer access macros should be part of the limited
> > API. If they are truely important (which I doubt), we should have
> > equivalent functions for them.
> 
> I thought the whole Py_buffer API was only temporarily removed from the
> limited API until the issues were sorted out:
> 
> http://bugs.python.org/issue10181#msg125462

I'm talking about the memoryview access macros. It's like
PyList_GET_SIZE, it isn't part of the limited API and you have to use
PyList_GetSize instead.

The limited API promises binary (ABI) compatibility accross releases.
It's a very strong promise to make and we must be careful not to put too
much stuff in the limited API. I don't think the rule for inclusion is
"we should put everything useful in the limited API".

> For instance, here the macros are not excluded:
> 
> http://hg.python.org/cpython/file/3292cc222d5c/Include/memoryobject.h

It might be a mistake, then.

> As for the two macros specifically, I know Pauli was using them:
> 
> http://bugs.python.org/issue10181#msg139775

Well, Pauli might use them, but it just means his code isn't compatible
with the limited API, then.

> The flags are primarily for the memoryview itself to avoid repeated calls
> to PyBuffer_IsContiguous(). So when 3rd-party uses PyMemoryView_GET_BUFFER
> to get the view and also needs to determine the contiguity type, that
> code could also use the flags.

But why would 3rd-party code use PyMemoryView_GET_BUFFER instead of, for
example, PyObject_GetBuffer? You seldom have APIs which *expect* a
memoryview, I think. Instead, they would expect a buffer-compatible
object.