[Python-Dev] PEP 3118: Extended buffer protocol (new version) (original) (raw)
Travis Oliphant oliphant.travis at ieee.org
Thu Apr 12 04:06:58 CEST 2007
- Previous message: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
- Next message: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Greg Ewing wrote:
From PEP 3118:
A memory-view object is an extended buffer object that should replace the buffer object in Python 3K. typedef struct { PyObjectHEAD PyObject *base; struct bufferinfo view; int itemsize; int flags; } PyMemoryViewObject; If the purpose is to provide Python-level access to an object via its buffer interface, then keeping a bufferinfo struct in it is the wrong implementation strategy, since it implies keeping the base object's memory locked as long as the view object exists.
Yes, but that was the intention. The MemoryView Object is basically an N-d array object.
That was the mistake made by the original buffer object, and the solution is not to hold onto the info returned by the base object's buffer interface, but to make a new buffer request for each Python-level access. I could see this approach also, but if we went this way then the memory view object should hold "slice" information so that it can be a "sliced" view of a memory area.
Because slicing NumPy array's already does it by holding on to a view, I guess having an object that doesn't hold on to a view in Python but "re-gets" it every time it is needed, would be useful.
In that case:
typedef struct { PyObject_HEAD PyObject *base; int ndims; PyObject *slices; / or 3 Py_ssize_t arrays */ int flags; } PyMemoryViewObject;
would be enough to store, I suppose.
-Travis
- Previous message: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
- Next message: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]