On Mo, 2016-09-05 at 18:19 -0500, Nathan Goldbaum wrote: > > > On Monday, September 5, 2016, Marten van Kerkwijk <m.h.vankerkwijk@gm > ail.com> wrote: > > Hi Sebastian, > > > > It would seem to me that any subclass has to keep up to date with > > new > > features in ndarray, and while I think ndarray has a responsibility > > not to break backward compatibility, I do not think it has to > > protect > > against new features possibly not working as expected in > > subclasses. > > In particular, I think it is overly complicated (and an unnecessary > > maintenance burden) to error out if a subclass has `__getitem__` > > overwritten, but not `oindex`. > > > > For somewhat similar reasons, I'm not too keen on a new > > `__numpy_getitem__` method; I realise it might reduce complexity > > for > > some ndarray subclasses eventually, but it also is an additional > > maintenance burden. If you really think it is useful, I think it > > might > > be more helpful to define a new mixin class which provides a > > version > > of all indexing methods that just call `__numpy_getitem__` if that > > is > > provided by the class that uses the mixin. I would *not* put it in > > `ndarray` proper. > I disagree that multiple inheritance (i.e. with your proposed mixin > and ndarray) is something that numpy should enshrine in its API for > subclasses. As the maintainer of an ndarray subclass, I'd much rather > prefer just to implement a new duner method that older numpy versions > will ignore. >
Hmm, OK, so that would be a + for the method solution even without the need of any of the extra capabilities that may be possible. > > > > Indeed, the above might even be handier for subclasses, since they > > can > > choose, if they wish, to implement a similar mixin for older numpy > > versions, so that all the numpy version stuff can be moved to a > > single > > location. (E.g., I can imagine doing the same for > > `__numpy_ufunc__`.) > > > > Overall, my sense would be to keep your PR to just implementing the > > various new index methods (which are great -- I still don't really > > like the names, but sadly don't have better suggestions...). > > > > But it might be good if others pipe in here too, in particular > > those > > maintaining ndarray subclasses! > > > > All the best, > > > > Marten > > _______________________________________________ > > 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
