Antoine Pitrou wrote: > That doesn't work if e.g. you take a slice of a memoryview object, since the > shape changes in the process. > See http://bugs.python.org/issue4580 I haven't looked in detail at how memoryview is currently implemented, but it seems to me that the way it should work is that whenever you access a slice, it obtains a fresh Py_Buffer from the underlying object, and does the right thing based on the shape/strides from that together with the slice ranges. The only time it should need to allocate its own shape/strides is if you request a Py_Buffer from the memoryview itself, at which time it should obtain a Py_Buffer from the underlying object, update its own shape/strides and pass them to the caller. The underlying Py_Buffer lock should be held until the caller releases the memoryview's Py_Buffer, ensuring that its shape/strides remains valid for as long as they're needed. -- Greg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4