Nick Coghlan wrote: > Antoine Pitrou wrote: >> In all honesty, I admit I am annoyed by all the problems with the buffer API / >> memoryview object, many of which are caused by its utterly bizarre design (and >> the fact that the design team went missing in action after imposing such a >> bizarre and complex design on us), and I'm reluctant to add yet another level of >> byzantine complexity in order to solve those problems. It explains I may sound a >> bit angry at times :-) >> >> If we really need to change things a lot to make them work, we should re-work >> the buffer API from the ground up, make the Py_buffer struct a true PyObject >> (that is, a true variable-length object so as to solve the shape and strides >> allocation issue) and merge it with the current memoryview implementation. It >> would make things both more simpler and more flexible. > > I don't see anything wrong with the PEP 3118 protocol. It does exactly > what it is designed to do: allow the number crunching crowd to share > large datasets between different libraries without copying things around > in memory. Yes, the protocol is complicated, but that is because it is > trying to handle a complicated problem. > > The memoryview implementation on the other hand is pretty broken. I do > have a theory on how it ended up in such an unusable state, but I'm not > particularly inclined to share it - this kind of thing can happen > sometimes, and the important question now is how we fix it. > Thank you Nick. This is a correct assessment of the situation. I'd like to help improve memoryview as I can. It does need thought about what you want memoryview to be. I wanted memoryview to be able to be sliced and diced (much like NumPy arrays). But, I only was able to get around to implementing the (simple view of Py_buffer struct). -Travis
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