On 2 Nov 2017, at 22:39, Marten van Kerkwijk m.h.vankerkwijk@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@python.org https://mail.python.org/mailman/listinfo/numpy-discussion