Antoine Pitrou wrote: > - it uses something (Py_buffer) which is not a PyObject and has totally > different allocation/lifetime semantics This was a deliberate decision -- in fact I argued for it myself. The buffer interface is meant to be a minimal-overhead way for C code to get at the underlying data. Requiring allocation of a PyObject would be too expensive. The way to think about the Py_buffer struct is not as an object in its own right, but just a place to put some output parameters from the GetBuffer call. The lifetime of the information pointed to by the Py_buffer is the same as the lifetime of the underlying object, and that object is responsible for managing it. > - it doesn't specify how to obtain e.g. a sub-buffer, or even duplicate an > existing one (which seem to be rather fundamental actions to me) I don't think they're as fundamental as all that. But some utilities for doing things like this could be useful, as I mentioned in another post. -- 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