The memoryview object in Python 3.0 needs to be finished.  There are a
few methods that are not complete.  In particular, the __getitem__ and
__setitem__ functionality needs to be finished as well as the tolist()
method.

Raising priority.

Also, the implementation does not follow the revised buffer PEP 3118. It
still calls get/releasebuffer(NULL) to acquire a lock, which is no
longer allowed by the buffer protocol.

I think this should become a release blocker for the last beta.

I agree, buffer interface should be completed before going into rc phase.

See also #3560.

Here is a preliminary patch implementing slices with getitem, adding a
bunch of tests, and fixing a few problems.

As stated elsewhere I only bother to test with simple byte buffers. The
semantics of other types of buffers are too fuzzy for me.

Antoine, if this is a "cleanup", perhaps you could fix #3101 while
you're at it.

Here is another patch with setitem too (integers and slices supported),
and further tests.

This patch fixes a crash in the codecs module.
However, memoryview should also support comparisons (just == and !=)
with bytes/bytearray objects (or any buffer-enabled objects), otherwise
utf-8-sig produces wrong values (and there are no tests for it).

Here is a patch to support comparisons of memoryview objects with other
objects offering the buffer interface. Two objects are equal if their
buffers have the same characteristics and compare equal bytewise.
It also improves the test in test_codecs.py, ensuring the problem has
been fixed.

Adding some comparison tests.

This patch changes all bytearray results (in indexing, tobytes()) to
bytes, and adds the implementation the tolist().

Note: the tolist() implementation only handles one-dimensional byte
buffers. It will have to be re-written using the struct module!
But at least once that patch applied, I think we may drop down this bug
to critical.

Please review at http://codereview.appspot.com/3004

Committed in r65886 after review from Benjamin and some small fixes.

I'm downgrading this to critical for the remains of the memoryview API
(support for more format types, multi-dimensional objects...). Perhaps
those remainings will have to wait for 3.1.

Guido, do we retarget the rest of this to 3.1? It sounds more reasonable
to me.

It would have been nice to finish the memoryview object for 3.0, but I
ran into time constraints.  The pieces that are left can be pushed to 3.1

Great. It would be nice if you could at least do a quick review what has
been committed though.

It looks to me like the critical parts of this have been done, so I'm downgrading the priority.

I think this issue is now superseded by #10181 and #3132.