On Di, 2016-09-06 at 10:10 -0700, Stephan Hoyer wrote: > On Mon, Sep 5, 2016 at 6:02 PM, Marten van Kerkwijk <m.h.vankerkwijk@ > gmail.com> wrote: > > p.s. Just to be clear: personally, I think we should have neither > > `__numpy_getitem__` nor a mixin; we should just get the quite > > wonderful new indexing methods! > +1 > > I don't maintain ndarray subclasses (I prefer composition), but I > don't think it's too difficult to require implementing vindex and > oindex properties from scratch. >
Well, in some sense why I brought it up is masked arrays. They have quite a bit of code in `__getitem__` including doing an identical indexing operation to the mask. I suppose you can always solve it with such code: def __special_getitem__(self, index, method=None): # do magic if method is None: # (not sure if this gets passed the base class res = super()[index] elif method == "outer": res = super().oindex[index] # ... # more magic. def __getitem__(self, index): self.__special_getitem__(index) @property def oindex(self): # define class elsewhere I guess class _indexer(object): def __init__(self, arr): self.arr = arr def __getitem__(self, index) arr.__special_getitem__(index, method='oter') return _indexer(self) Though I am not 100% sure without testing, a superclass method that understands the `method` kwarg might work better. We can teach numpy to pass in that `method` to getitem so that you don't have to implement that `_indexer` class for the special attribute. I first started to do that for MaskedArrays, and while it is not hard, it seemed a bit tedious. If we move this to a method with a new name, a slight advantage would be that other oddities could be removed maybe. By now it seems to me that nobody really needs the extra information (i.e. preprocessing information of the indexing tuple)...? I thought it could be useful to know things about the result, but I suppose you can check most things (view vs. no view; field access; scalar access) also afterwards? > Side note: I would prefer the more verbose "legacy_index" to > "lindex". We really want to discourage this one, and two new > abbreviations are bad enough. Sounds good to me. > _______________________________________________ > 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
