On Thu, Jul 19, 2012 at 2:53 PM, Travis Oliphant <[email protected]> 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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
