On Mo, 2016-09-05 at 18:24 -0400, Marten van Kerkwijk 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`. >
It is not complicated implementation wise to check for `__getitem__` existence. However, I start to agree that a warning icould be the better option. It might work after all. > 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. > Yes, that is maybe a simplier option (in the sense of maintainability), the other would have a bit of extra information available. If this extra information is unnecessary, a MixIn is probably a bit simpler. > 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__`.) > You can always implement a mixin for older verions if you do all the logic yourself, but I would prefer not to duplicate that logic (Jaime wrote a python class that does it for normal arrays -- not sure if its 100% the same as I did, but you could probably use it in a subclass). So that a numpy provided mixin would not help with that supporting it in old numpy versions, I think. > 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...). > Well... The thing is that we have to fix the subclasses within numpy as well (most importantly MaskedArrays). Of course you could delay things a bit, but in the end whatever we use internally could likely also be whatever subclasses might end up using. > But it might be good if others pipe in here too, in particular those > maintaining ndarray subclasses! > Yeah :). > All the best, > > Marten > _______________________________________________ > 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
