Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Copy & paste from python-dev post:
The problem with memoryview appears to be related to the way it
calculates its own length (since that is the check that is failing when
the view blows up):
>>> a = array('i', range(10))
>>> m = memoryview(a)
>>> len(m) # This is the length in bytes, which is WRONG!
40
>>> m2 = memoryview(a)[2:8]
>>> len(m2) # This is correct
6
>>> a2 = array('i', range(6))
>>> m[:] = a # But this works
>>> m2[:] = a2 # and this does not
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: cannot modify size of memoryview object
>>> len(memoryview(a2)) # Ah, 24 != 6 is our problem!
24
Looks to me like there are a couple of bugs here:
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).
The second is that the getbuf implementation in array.array is broken.
It is ONLY OK for shape to be null when ndim=0 (i.e. a scalar value). An
array is NOT a scalar value, so the array objects should be setting the
shape pointer to point to an single item array (where shape[0] is the
length of the array).
memoryview can then be fixed to use shape[0] instead of len to get the
number of objects in the view.
----------
nosy: +ncoghlan
_______________________________________
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4580>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
