On So, 2016-09-04 at 14:10 +0200, Sebastian Berg wrote: > 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. > ```
Hmm, field access is a bit annoying, but I guess can/has to be included. > > 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 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion