Stefan Krah <stefan-use...@bytereef.org> added the comment: Antoine Pitrou <rep...@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 For instance, here the macros are not excluded: http://hg.python.org/cpython/file/3292cc222d5c/Include/memoryobject.h Since the issues seem resolved in general, I thought it was time to restore the previous state. [I just noticed that I didn't revert all of Martin's changes, so xxlimited currently does not build in the pep-3118 repo.] As for the two macros specifically, I know Pauli was using them: http://bugs.python.org/issue10181#msg139775 > > I think it might be OK to defer the decision about Py_MEMORYVIEW_C etc., > > since the comment already says "... Don't access their fields directly.". > > My question is whether there is any point in making these flags. Does > 3rd-party code want to manipulate memoryview internals, instead of > querying the Py_buffer? 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. Pauli: If you are still following the issue, do you think having access to contiguity flags is useful for 3rd-party code or not? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10181> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
