Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

I think that with your comments in mind, it may just be best to embrace duck typing, like Matthew suggested. I propose the following workflow: - __array_concatenate__ and similar "protocol" functions return NotImplemented if they won't work. - "Base functions" that can be called directly

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Sat, Mar 10, 2018 at 4:27 AM, Matthew Rocklin wrote: > I'm very glad to see this discussion. > > I think that coming up with a single definition of array-like may be > difficult, and that we might end up wanting to embrace duck typing instead. > > It seems to me that different array-like classe

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Yes, a tuple of types would make more sense, given `isinstance` -- string abbreviations for those could be there for convenience. -- Marten On Sat, Mar 17, 2018 at 8:25 PM, Eric Wieser wrote: > I would have thought that a simple tuple of types would be more appropriate > than using integer flags

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

I would have thought that a simple tuple of types would be more appropriate than using integer flags, since that means that isinstance can be used on the individual elements. Ideally there’d be a typing.Intersection[TraitA, TraitB] for this kind of thing. ​ On Sat, 17 Mar 2018 at 15:10 Thomas Casw

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Yes, meant IntFlag :sheep: On Sat, Mar 17, 2018 at 6:02 PM Hameer Abbasi wrote: > > It would be nice if there was an IntEnum [1] that was taken is an input to > `np.asarrayish` and `np.isarrayish` to require a combination of the groups > of attributes/methods/semantics. > > > Don’t you mean IntF

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

It would be nice if there was an IntEnum [1] that was taken is an input to `np.asarrayish` and `np.isarrayish` to require a combination of the groups of attributes/methods/semantics. Don’t you mean IntFlag ? I like Marten’s idea of “grouping to

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

It would be nice if there was an IntEnum [1] that was taken is an input to `np.asarrayish` and `np.isarrayish` to require a combination of the groups of attributes/methods/semantics. Tom [1] https://docs.python.org/3/library/enum.html#intenum On Sat, Mar 10, 2018 at 7:14 PM Marten van Kerkwijk <

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

​I think we don't have to make it sounds like there are *that* many types of compatibility: really there is just array organisation (indexing/reshaping) and array arithmetic. These correspond roughly to ShapedLikeNDArray in astropy and NDArrayOperatorMixin in numpy (missing so far is concatenation)

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Sat, Mar 10, 2018 at 1:27 PM, Matthew Rocklin wrote: > I'm very glad to see this discussion. > me too, but > I think that coming up with a single definition of array-like may be > difficult, and that we might end up wanting to embrace duck typing instead. > exactly -- I think there is

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

I'm very glad to see this discussion. I think that coming up with a single definition of array-like may be difficult, and that we might end up wanting to embrace duck typing instead. It seems to me that different array-like classes will implement different mixtures of features. It may be difficu

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, Mar 8, 2018 at 5:51 PM, Juan Nunez-Iglesias wrote: >> Finally for the name, what about `asduckarray`? Thought perhaps that could >> be a source of confusion, and given the gradation of duck array like types. > > I suggest that the name should *not* use programmer lingo, so neither > "abstr

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, Mar 8, 2018 at 9:45 PM, Stephan Hoyer wrote: > On Thu, Mar 8, 2018 at 5:54 PM Juan Nunez-Iglesias > wrote: >> >> On Fri, Mar 9, 2018, at 5:56 AM, Stephan Hoyer wrote: >> >> Marten's case 1: works exactly like ndarray, but stores data differently: >> parallel arrays (e.g., dask.array), spa

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

We may be getting a bit distracted by the naming -- though I'll throw out `asarraymimic` as another non-programmer-lingo option that doesn't reuse `arraylike` and might describe what the duck array is attempting to do more closely. But more to the point: I think in essence, we're trying to create

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Fri, Mar 9, 2018 at 12:21 AM, Hameer Abbasi wrote: > Not that I’m against different “levels” of ndarray granularity, but I just > don’t want it to introduce complexity for the end-user. For example, it > would be unreasonable to expect the end-user to check for all parts of the > interface tha

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Fri, Mar 9, 2018 at 2:29 AM, Nathaniel Smith wrote: > On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk > wrote: > > A larger comment: you state that you think `np.asanyarray` is a > > mistake since `np.matrix` and `np.ma.MaskedArray` would pass through > > and that those do not strictly mi

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, 2018-03-08 at 18:56 +, Stephan Hoyer wrote: > Hi Nathaniel, > > Thanks for starting the discussion! > > Like Marten says, I think it would be useful to more clearly define > what it means to be an abstract array. ndarray has lots of > methods/properties that expose internal implementa

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk wrote: > A larger comment: you state that you think `np.asanyarray` is a > mistake since `np.matrix` and `np.ma.MaskedArray` would pass through > and that those do not strictly mimic `NDArray`. Here, I agree with > `matrix` (but since we're depre

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Not that I’m against different “levels” of ndarray granularity, but I just don’t want it to introduce complexity for the end-user. For example, it would be unreasonable to expect the end-user to check for all parts of the interface that they need support for separately. Keeping this in view; diffe

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, Mar 8, 2018 at 5:54 PM Juan Nunez-Iglesias wrote: > On Fri, Mar 9, 2018, at 5:56 AM, Stephan Hoyer wrote: > > Marten's case 1: works exactly like ndarray, but stores data differently: > parallel arrays (e.g., dask.array), sparse arrays (e.g., > https://github.com/pydata/sparse), hypotheti

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Fri, Mar 9, 2018, at 5:56 AM, Stephan Hoyer wrote: > Marten's case 1: works exactly like ndarray, but stores data > differently: parallel arrays (e.g., dask.array), sparse arrays (e.g., > https://github.com/pydata/sparse), hypothetical non-strided arrays > (e.g., always C ordered). Two other "hy

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Hi Nathaniel, Thanks for starting the discussion! Like Marten says, I think it would be useful to more clearly define what it means to be an abstract array. ndarray has lots of methods/properties that expose internal implementation (e.g., view, strides) that presumably we don't want to require as

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Hi Nathaniel, Overall, hugely in favour! For detailed comments, it would be good to have a link to a PR; could you put that up? A larger comment: you state that you think `np.asanyarray` is a mistake since `np.matrix` and `np.ma.MaskedArray` would pass through and that those do not strictly mimi

[Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Hi all, Here's a more substantive NEP: trying to define how to define a standard way for functions to say that they can accept any "duck array". Biggest open question for me: the name "asabstractarray" kinda sucks (for reasons described in the NEP), and I'd love to have something better. Any idea