Le mardi 09 décembre 2008 à 22:33 +1000, Nick Coghlan a écrit : > I have zero problem whatsoever if slice assignment TO a memoryview > object is permitted only if the shape stays the same (i.e. I think that > issue should be closed as "not a bug"). I'm not even talking about slice /assignment/ here, just read-only slicing. Slicing a memoryview must produce another memoryview with a different shape but with the same underlying object. That's why I have to modify the shape field /after/ the new Py_buffer is initialized. > The buffer protocol permits you to edit the DATA held by another > object. It doesn't let you edit the *structure* of that object Perhaps, but it's necessary for slicing. > The first is that memoryview is treating the len field in the > Py_buffer struct as the number of objects in the view in a few places > instead of as the total number of bytes being exposed (it is actually > the latter, as defined in PEP 3118). I don't understand the difference between "the number of objects in the view" and "the total number of bytes being exposed". For me it should be the same and the "buf" and "len" fields in the Py_buffer should be usable by any other C function, otherwise they are useless. > memoryview also currently gets the shape wrong on slices: I know, that's what I'm trying to fix...
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