[Numpy-discussion] is __array_ufunc__ ready for prime-time?

[Ben Rowland]

> On 2 Nov 2017, at 22:39, Marten van Kerkwijk <m.h.vankerkwijk at gmail.com> wrote:
> 
> I guess my argument boils down to it being better to state that a
> function only accepts arrays and happily let it break on, e.g.,
> matrix, than use `asarray` to make a matrix into an array even though
> it really isn’t.

I would support this attitude, the user can always call `asarray` when passing their
data into the function if necessary, then they know upfront what the consequences
will be.

For my own ndarray subclass, I want it to behave exactly as a standard ndarray,
but in addition I add some metadata and some functions that act on that, for
example an affine transform and functions to convert between coordinate systems.
The current numpy system of overriding __array_wrap__, __array_finalize__ and
__new__ is great to allow the subclass and metadata to propagate through most
basic operations.

The problem is that many functions using `asarray` strip out all of this metadata
and return a bare ndarray. My current solution is to implement an `inherit` method
on my subclass which converts an ndarray and copies back all the metadata,
which often looks like this:
spec_data = data.inherit(np.fft.fft(data))

To use composition instead of inheritance would require me to forward every part
of the ndarray API as is, which would be a great deal of work which in nearly
every case would only achieve the same results as replacing `asarray` by
`asanyarray` in various library functions. I don’t want to change the behaviour of
the existing class, just to add some data and methods, and I can’t imagine I am
alone in that.

Ben

> 
> I do like the dtype ideas, but think I'd agree they're likely to come
> with their own problems. But just making new numerical types possible
> is interesting.
> 
> -- Marten
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion