On 9 Sep 2013 22:58, "Oscar Benjamin" <oscar.j.benjamin@gmail.com> wrote:
>
> On 9 September 2013 12:56, Nick Coghlan <ncoghlan@gmail.com> wrote:
> >> Alternatively, I thought there was discussion a long time ago about
> >> getting numpy's
> >> (or even further back, numeric's?) array type into the core. Python
> >> has an array type
> >> which I don't think gets a lot of use (or love). Might it be
> >> worthwhile to make sure the
> >> PEP 450 package works with that? Then extend it to multiple dimensions? Or
> >> just
> >> bite the bullet and get numpy's array type into the Python core once
> >> and for all?
> >>
> >> Sort of Tulip for arrays...
> >
> > Aka memoryview :)
> >
> > Stefan Krah already fixed most of the multidimensional support issues in 3.3
> > (including the "cast" method to reinterpret the contents in a different
> > format). The main missing API elements are multidimensional slicing and the
> > ability to export them from types defined in Python.
>
> Being very familiar with numpy's ndarrays and not so much with
> memoryviews this prompted me to go and have a look at them.
>
> How exactly are you supposed to create a multidimensional array using
> memoryviews? The best I could come up with was something like:
>
> $ py -3.3
> Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600
> 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import array
> >>> v = memoryview(array.array('b', [1, 2, 3, 4])).cast('b', (2, 2))
> >>> v.shape
> (2, 2)
>
> However I don't seem to be able to access the elements:
>
> >>> v[0, 1]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: memoryview: invalid slice key
> >>> v[0]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NotImplementedError: multi-dimensional sub-views are not implemented
> >>> v[0:1]
> <memory at 0x00DF8B70>
> >>> v[0:1].shape
> (1, 2)
> >>> v[0:1][0]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NotImplementedError: multi-dimensional sub-views are not implemented
> >>> v[1]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NotImplementedError: multi-dimensional sub-views are not implemented
> >>> v[:, 1]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: memoryview: invalid slice key
> >>> v[1, :]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: memoryview: invalid slice key
>
> And the .cast method bails if you try to use a more useful type code:
>
> >>> v = memoryview(array.array('q', [1, 2, 3, 4])).cast('q', (2, 2))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: memoryview: cannot cast between two non-byte formats

Oops, forgot the type casting restrictions, too.

My main point was that PEP 3118 is already intended as the tulip equivalent for multi-dimensional arrays, and memoryview is the stdlib API for that. It's just incomplete, since most serious multi-dimensional use cases involve skipping memoryview and go straight to NumPy or one of the image libraries.

As far as I am aware, there's no opposition to fixing the multi-dimensional support in memoryview *per se*, just the usual concerns about maintainability and a question of volunteers with the time to actually resolve the relevant open issues on the bug tracker. The fairly extensive 3.3 changes focused on fixing stuff that was previously outright broken, but several limitations remain, often because the best API wasn't clear, or because it reached the point where "just use NumPy" seemed like a justifiable answer.

Cheers,
Nick.

>
>
> Oscar