This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients Arfrever, georg.brandl, mark.dickinson, meador.inge, pitrou, python-dev, skrah, vstinner
Date 2012-08-06.08:47:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
STINNER Victor <> 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
>>> x == y

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:

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).
Date User Action Args
2012-08-06 08:47:28skrahsetrecipients: + skrah, georg.brandl, mark.dickinson, pitrou, vstinner, Arfrever, meador.inge, python-dev
2012-08-06 08:47:28skrahlinkissue13072 messages
2012-08-06 08:47:27skrahcreate