Nick Coghlan <ncogh...@gmail.com> added the comment: The managed buffer needs to be a separate object so that multiple memoryview objects can share it. Essentially, we would end up with two APIs - the raw Py_buffer API and the higher level PyManagedBuffer one.
C extensions would have the choice of using the low level API (most likely the case for existing extensions) or making life easier for themselves by using the higher level one. It is, at least from the consumer side, almost exactly what you suggested in the first place: a PEP 3118 style API where the main interface object is a true PyObject instance. Providers will still need to deal with correctly populating the passed in Py_buffer instances, but that can be handled easily enough by storing exported managed buffers in a Python list and storing indices in the Py_buffer internal field. PyMemoryView itself isn't appropriate as that higher level API, since it does a lot more than just provide an easy way to share a Py_buffer struct (specifically, thanks to slicing, a memoryview instance may not expose the entire underlying buffer). Managed buffers would be much simpler, simply providing read-only access to the fields of the managed Py_buffer struct. Depending on how we end up defining the required consumer semantics, PyMemoryView_FromBuffer may or may not be fully salvageable. If we find dup_buffer semantics that are universally correct, then we may be able to keep it in its current form by building those into an alternate ManagedBuffer constructor, otherwise we may need to restrict it to cases where the obj field is NULL. ---------- _______________________________________ 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
