Stefan Krah added the comment:
STINNER Victor <rep...@bugs.python.org> wrote:
> Hum, this issue is a regression from Python 3.2.
>
> Python 3.2.3+ (3.2:243ad1a6f638+, Aug 4 2012, 01:36:41)
> [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
> >>> import array
> >>> a=array.array('u', 'xyz')
> >>> b=memoryview(a)
> >>> a == b
> True
> >>> b == a
> True
[3.3 returns False]
That's actually deliberate. The new memoryview does not consider arrays equal
if the format codes do not match, to avoid situations like (32-bit Python):
Python 3.2a0 (py3k:76143M, Nov 7 2009, 17:05:38)
[GCC 4.2.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import array
>>> a = array.array('f', [0])
>>> b = array.array('i', [0])
>>> x = memoryview(a)
>>> y = memoryview(b)
>>>
>>> a == b
True
>>> x == y
True
>>>
I think that (for buffers at least) an array of float should not compare
equal to an array of int, especially since the 3.2 memoryview uses memcmp()
in richcompare().
See also the comment in the documentation for memoryview.format:
http://docs.python.org/dev/library/stdtypes.html#memoryview-type
memoryview is not aware of the 'u' format code, since it's not part of
the struct syntax and the PEP-3118 proposition 'u' -> UCS2, 'w' -> UCS4
wasn't considered useful.
Now in your example I see that array's getbufferproc actually already uses
'w' for UCS4. It would still be an option to make memoryview aware of
'u' and 'w' (as suggested by the PEP).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13072>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
