[Numpy-discussion] Indexing API

[Nathaniel Smith]

On Thu, Jul 19, 2012 at 2:53 PM, Travis Oliphant <travis at continuum.io> wrote:
>
> On Jul 19, 2012, at 3:50 AM, Nathaniel Smith wrote:
>
>> So the underlying problem with the controversial inplace_increment
>> PR[1] is that currently, there's actually nothing in the public numpy
>> API that exposes the workings of numpy indexing. The only thing you
>> can do with a numpy index is call ndarray.__getattr__ or __setattr__.
>> This is a pretty obvious gap, given how fundamental an operation
>> indexing is in numpy (and how difficult to emulate). So how can we
>> expose something that fixes it? Make PyArrayMapIterObject part of the
>> public API? Something else?
>
> I think you meant ndarray.__getitem__ and ndarray.__setitem__
>
> As I mentioned in the comments, the original intention was to make PyArrayMapIterObject part of the public API.   However, I was not able to make it work in the way I had intended back then.
>
> Exposing the MapIterObject is a good idea (but it would have to be exposed already bound to an array) --- i.e. you create a new API that binds to a particular array and then expose the PyArray_MapIterNext, etc. functions.
>
> Perhaps something like:   PyArray_MapIterArray

There's now a PR for exposing this:
  https://github.com/numpy/numpy/pull/377
Since this is new API I hope people will take a look :-).

The patch itself is pretty trivial, but it exposes an object that
seems to have been only partially implemented, so we should also
double-check that this isn't exposing any half-baked code. (mapping.c
still says "Do not expose the MapIter_Type to Python", but I'm not
really clear what the problems are. AFAICT it doesn't actually define
*any* Python-accessible API, it's just an opaque object.)

-n