Hi All,
At the moment there are two error types raised when invalid axis arguments
are encountered: IndexError and ValueError. I prefer ValueError for
arguments, IndexError seems more appropriate when the bad axis value is
used as an index. In any case, having mixed error types is inconvenient,
bu
On Mo, 2016-09-05 at 11:54 -0600, Charles R Harris wrote:
> Hi All,
>
> At the moment there are two error types raised when invalid axis
> arguments are encountered: IndexError and ValueError. I prefer
> ValueError for arguments, IndexError seems more appropriate when the
> bad axis value is used
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 larg
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, sin
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 part
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
___
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 think it has to protect
> agains
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 fe
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
https://mail.scipy.org/mailman/lis
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
> aga
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 ndarray has a responsib
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 mask,
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, mode='oute
13 matches
Mail list logo
