Message139162
| Author |
skrah |
| Recipients |
jcon, kermode, mark.dickinson, ncoghlan, pitrou, pv, rupole, skrah, teoliphant |
| Date |
2011年06月26日.10:30:19 |
| SpamBayes Score |
1.6928031e-10 |
| Marked as misclassified |
No |
| Message-id |
<1309084220.89.0.0599907558798.issue10181@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
[Nick]
> Another idea we may want to revisit is the PyManagedBuffer concept,
> which would be a true PyObject that existed solely to simplify sharing
> of Py_buffer structs.
> If memoryview used such an object internally, then copying and slicing
> would be quite simple - just INCREF the managed buffer instance without
> letting the original source object know anything was going on.
I think this is the nicest solution since memoryview would then always
have a proper base object. Do I understand correctly that PyManagedBuffer
should only handle 1-dimensional objects?
There is an additional point about slicing and sub-views:
I think slicing (esp. multidimensional slicing) would be greatly simplified
if we added a requirement for the *exporting* object to provide a sliced
view. (The same applies to sub-views, also see source comments below [1]).
For example, an exporting object could provide a sliced view by adding
a getslicedbufferproc to PyBufferProcs:
int PyObject_GetSlicedBuffer(PyObject *obj, Py_buffer *view, int flags, PyObject *key);
By "sliced view" I mean that the exporting object changes buf, shape and
strides. There are several advantages:
o The invariant that all allocated memory in the buffer belongs
to the exporting object remains intact.
o The responsibility for creating correct multidimensional sliced views
is shifted to the implementor of the exporting object.
[1] memoryobject.c:
/* XXX There should be an API to create a subbuffer */
/* XXX: This needs to be fixed so it actually returns a sub-view */ |
|