Message239783
| Author |
martin.panter |
| Recipients |
docs@python, ezio.melotti, martin.panter, r.david.murray, serhiy.storchaka |
| Date |
2015年04月01日.11:33:04 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1427887985.65.0.322156397009.issue23756@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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 |
|