Message239783
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 |
|
Date |
User |
Action |
Args |
2015-04-01 11:33:05 | martin.panter | set | recipients:
+ martin.panter, ezio.melotti, r.david.murray, docs@python, serhiy.storchaka |
2015-04-01 11:33:05 | martin.panter | set | messageid: <1427887985.65.0.322156397009.issue23756@psf.upfronthosting.co.za> |
2015-04-01 11:33:05 | martin.panter | link | issue23756 messages |
2015-04-01 11:33:05 | martin.panter | create | |
|