Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On So, 2016-09-11 at 11:19 -0400, Marten van Kerkwijk wrote: > There remains the option to just let subclasses deal with new ndarray > features...  Certainly, for `Quantity`, I'll quite happily do that. > And if it alllows the ndarray code to remain simple and efficient, it > is probably the best

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

There remains the option to just let subclasses deal with new ndarray features... Certainly, for `Quantity`, I'll quite happily do that. And if it alllows the ndarray code to remain simple and efficient, it is probably the best solution. -- Marten ___

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 13:59 -0400, Marten van Kerkwijk wrote: > In a separate message, since perhaps a little less looney: yet > another > option would be work by analogy with np.ix_ and define pre-dispatch > index preparation routines np.ox_ and np.vx_ (say), which would be > used as in: > ``` >

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 13:59 -0400, Marten van Kerkwijk wrote: > In a separate message, since perhaps a little less looney: yet > another > option would be work by analogy with np.ix_ and define pre-dispatch > index preparation routines np.ox_ and np.vx_ (say), which would be > used as in: > ``` >

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 10:10 -0700, Stephan Hoyer wrote: > On Mon, Sep 5, 2016 at 6:02 PM, Marten van Kerkwijk 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

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

In a separate message, since perhaps a little less looney: yet another option would be work by analogy with np.ix_ and define pre-dispatch index preparation routines np.ox_ and np.vx_ (say), which would be used as in: ``` array[np.ox_[:, 10]] -- or -- array[np.vx_[:, 10]] ``` This could work if

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

I'd love to solve it with `__getitem__`... Since most subclasses will have that defined that with just a single argument, calling it from `oindex` with an extra mode argument set will properly fail, so good in that sense (although one better ensure a useful error message...). Another option would

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

I'm also in the non-subclass array-like camp, and I'd love to just write vindex and oindex methods, then have: def __getitem__(self, idx): return np.dispatch_getitem(self, idx) Where "dispatch_getitem" does some basic argument checking and calls either vindex or oindex as appropriate. Maybe

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Tuesday, September 6, 2016, Stephan Hoyer wrote: > On Mon, Sep 5, 2016 at 6:02 PM, Marten van Kerkwijk < > m.h.vankerkw...@gmail.com > > wrote: > >> p.s. Just to be clear: personally, I think we should have neither

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mon, Sep 5, 2016 at 6:02 PM, Marten van Kerkwijk < m.h.vankerkw...@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

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 10:57 +0100, Robert Kern wrote: > On Tue, Sep 6, 2016 at 8:46 AM, Sebastian Berg s.net> wrote: > > > > On Di, 2016-09-06 at 09:37 +0200, Sebastian Berg wrote: > > > On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > > > > > > > > Actually,

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Tue, Sep 6, 2016 at 8:46 AM, Sebastian Berg wrote: > > On Di, 2016-09-06 at 09:37 +0200, Sebastian Berg wrote: > > On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > > > > > > Actually, on those names: an alternative to your proposal would be > > > to >

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 09:37 +0200, Sebastian Berg wrote: > On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > > > > Actually, on those names: an alternative to your proposal would be > > to > > introduce only one new method which can do all types of indexing, > > depending on a keyword

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > Actually, on those names: an alternative to your proposal would be to > introduce only one new method which can do all types of indexing, > depending on a keyword argument, i.e., something like > ``` > def getitem(self, item,

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 21:02 -0400, Marten van Kerkwijk 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! Hehe, yes but see MaskedArrays. They need logic to also index the

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > Actually, on those names: an alternative to your proposal would be to > introduce only one new method which can do all types of indexing, > depending on a keyword argument, i.e., something like > ``` > def getitem(self, item,

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 18:19 -0500, Nathan Goldbaum wrote: > > > On Monday, September 5, 2016, Marten van Kerkwijk 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

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

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 >

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

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! ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

Hi Nathan, The question originally posed is whether `ndarray` should provide that single method as a convenience already, even though it doesn't actually use it itself. Do you think that is useful, i.e., a big advantage over overwriting the new oindex, vindex, and another that I forget? My own

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Monday, September 5, 2016, 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

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

Actually, on those names: an alternative to your proposal would be to introduce only one new method which can do all types of indexing, depending on a keyword argument, i.e., something like ``` def getitem(self, item, mode='outer'): ... ``` -- Marten

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

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

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 14:54 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > Indeed, having the scalar pass through `__array_wrap__` would have > been useful (_finalize__ is too late, since one cannot change the > class any more, just set attributes).  But that is water under the > bridge,

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

Hi Sebastian, Indeed, having the scalar pass through `__array_wrap__` would have been useful (_finalize__ is too late, since one cannot change the class any more, just set attributes). But that is water under the bridge, since we're stuck with people not expecting that. I think the slightly

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On So, 2016-09-04 at 11:20 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > I haven't given this as much thought as it deserves, but thought I > would comment from the astropy perspective, where we both have direct > subclasses of `ndarray` (`Quantity`, `Column`, `MaskedColumn`) and >

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

Hi Sebastian, I haven't given this as much thought as it deserves, but thought I would comment from the astropy perspective, where we both have direct subclasses of `ndarray` (`Quantity`, `Column`, `MaskedColumn`) and classes that store their data internally as ndarray (subclass) instances

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

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

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

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

[Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

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):