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, christian.heimes, georg.brandl, loewis, mark.dickinson, meador.inge, ncoghlan, pitrou, python-dev, skrah, vstinner
Date 2012-08-11.18:13:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20120811181307.GA30972@sleipnir.bytereef.org>
In-reply-to <1344658560.61.0.165773551095.issue15573@psf.upfronthosting.co.za>
Content
So we have two competing proposals:

1) Py_buffers are strongly typed arrays in the ML sense (e.g. array of float,
   array of int).

This is probably what I'd prefer on the C level, imagine a function like
function like PyBuffer_Compare(v, w).

Backwards compatibility problem for users who were thinking in terms of
value comparisons:

>>> x = array.array('b', [127])
>>> y = array.array('B', [127])
>>> x == y
True
>>> memoryview(x) == memoryview(y)
False

2) Compare by value, like NumPy arrays do:

>>> x = numpy.array([1, 2, 3], dtype='i')
>>> y = numpy.array([1, 2, 3], dtype='f')
>>> x == y
array([True,  True,  True], dtype=bool)

I concede that this is probably what users want to see on the Python level.

Backwards compatibility problem for users who were using complicated
structs:

>>> from _testbuffer import *
>>> x = ndarray([(1,1), (2,2), (3,3)], shape=[3], format='hQ')
>>> x == memoryview(x)
False

Reason: While _testbuffer.ndarray already implements tolist() in full
generality, memoryview does not:

>>> x.tolist()
[(1, 1), (2, 2), (3, 3)]

>>> memoryview(x).tolist()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: memoryview: unsupported format hQ

So while I'm beginning to like Martin's proposal, the implementation is
certainly trickier and will always be quite slow for complicated format
strings.

It would be possible to keep a fast path for the primitive C types
and use the code from _testbuffer.tolist() for the slow cases.
History
Date User Action Args
2012-08-11 18:13:07skrahsetrecipients: + skrah, loewis, georg.brandl, mark.dickinson, ncoghlan, pitrou, vstinner, christian.heimes, Arfrever, meador.inge, python-dev
2012-08-11 18:13:06skrahlinkissue15573 messages
2012-08-11 18:13:05skrahcreate