On Sa, 2016-09-03 at 21:08 +0200, Sebastian Berg wrote:
Hi all,
not that I am planning to spend much time on this right now, however, I did a small rebase of the stuff I had (did not push yet) on oindex and remembered the old problem ;).
The one remaining issue I have with adding things like (except making the code prettier and writing tests):
arr.oindex[...] # outer/orthogonal indexing arr.vindex[...] # Picking of elements (much like current) arr.lindex[...] # current behaviour for backward compat
is what to do about subclasses. Now what I can do (and have currently in my branch) is to tell someone on `subclass.oindex[...]`: This won't work, the subclass implements `__getitem__` or `__setitem__` so I don't know if the result would be correct (its a bit annoying if you also warn about using those attributes, but...).
Hmm, I am considering to expose a new indexing helper object. So that subclasses could implement something like `__numpy_getitem__` and `__numpy_setitem__` and if they do (and preferably nothing else) they would get back passed a small object with some information about the indexing operation. So that the subclass would implement: ``` def __numpy_setitem__(self, indexer, values): indexer.method # one of {"plain", "oindex", "vindex", "lindex"} indexer.scalar # Will the result be a scalar? indexer.view # Will the result be a view or a copy? # More information might be possible (note that not all checks are # done at this point, just basic checks will have happened already). # Do some code, that prepares self or values, could also use # indexer for another array (e.g. mask) of the same shape. result = indexer(self, values) # Do some coded to fixup the result if necessary. # Should discuss whether result is first a plain ndarray or # already wrapped. ``` This could be implemented in the C-side without much hassle, I think. Of course it adds some new API which we would have to support indefinitely. But it seems something like this would also fix the hassle of identifying e.g. if the result should be a scalar for a subclass (which may even be impossible in some cases). Would be very happy about feedback from subclassers! - Sebastian
However, with or without such error, we need a nice way for subclasses to define these attributes! This is important even within numpy at least for masked arrays (possibly also matrix and memmap).
They (typically) do some stuff before or after the plain indexing operation, so how do we make it convenient to allow them to do the same stuff for the special indexing attributes without weird code duplication? I can think of things, but nothing too great yet so maybe you guys got an elegant idea.
- Sebastian _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion