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
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
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
> > > introduce only one new me
Hi,
The general consensus seems to be in favour of using "NumPy" when referring to
the project and "numpy" as a module name.
Please note that there are currently PRs in 3 different repositories
implementing this practice:
- numpy docs: https://github.com/numpy/numpy/pull/8021
- numpy.org websi
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, on those names: an altern
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 (I
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
>> `__numpy_getitem__` nor a mixin; we should just get the quite
>> wonderful n
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
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
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 t
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 new indexing methods!
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:
> ```
> ar
On Fri, Sep 2, 2016 at 1:16 AM, Peter Creasey wrote:
> > I'm not quite sure which approach is state-of-the-art as of 2016. How
> would
> > you do it if you had to make a C/C++ library available in Python right
> now?
> >
> > In my case, I have a C library with some scientific functions on matrice
13 matches
Mail list logo
