Martin Panter added the comment: After doing a bit of reading and experimenting, I think we should at least restrict bytes-like objects to “C-contiguous”. Any looser definition risks memoryview(byteslike).tobytes() returning the bytes in a different order than their true in-memory order. Fortran-style contiguous arrays aren’t enough:
>>> import _testbuffer, sys >>> fortran = memoryview(_testbuffer.ndarray([11, 12, 21, 22], format="B", >>> flags=0, shape=[2, 2], strides=[1, 2], offset=0)) >>> fortran.f_contiguous True >>> fortran.c_contiguous False >>> fortran.tolist() [[11, 21], [12, 22]] >>> tuple(bytes(fortran)) (11, 21, 12, 22) >>> sys.stdout.buffer.write(fortran) Traceback (most recent call last): File "<stdin>", line 1, in <module> BufferError: memoryview: underlying buffer is not C-contiguous So I am proposing a patch which: * Restricts the bytes-like object definition to C-contiguous buffers * Explains what I think is actually meant by “contiguous” in the C API buffer protocol page. Turns out it is generally a more strict definition than I originally assumed. * Explains why memoryview.tobytes() is out of order for non C-contiguous buffers * Has a couple other fixes taking into acount memoryview.tolist() doesn’t work for zero dimensions, and is nested for more than one dimension ---------- keywords: +patch Added file: http://bugs.python.org/file38780/c-contig.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23756> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
