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 {
> PyObject_HEAD
> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
