[Numpy-discussion] Should ndarray subclasses support the keepdims arg?
sebastian at sipsolutions.net
Tue May 5 13:41:51 EDT 2015
On Di, 2015-05-05 at 11:13 -0400, Allan Haldane wrote:
> Hello all,
> A question:
> Many ndarray methods (eg sum, mean, any, min) have a "keepdims" keyword
> argument, but ndarray subclass methods sometimes don't. The 'matrix'
> subclass doesn't, and numpy functions like 'np.sum' intentionally
> drop/ignore the keepdims argument when called with an ndarray subclass
> as first argument.
> This means you can't always use ndarray subclasses as 'drop in'
> replacement for ndarrays if the code uses keepdims (even indirectly),
> and it means code that deals with keepdims (eg np.sum and more) has to
> detect ndarray subclasses and drop keepdims even if the subclass
> supports it (since there is no good way to detect support). It seems to
> me that if we are going to use inheritance, subclass methods should keep
> the signature of the parent class methods. What does the list think?
> ---- Details: ----
> This problem comes up in a PR I'm working on (#5706) to add the keepdims
> arg to masked array methods. In order to support masked matrices (which
> a lot of unit tests check), I would have to detect and drop the keepdims
> arg to avoid an exception. This would be solved if the matrix class
> supported keepdims (plus an update to np.sum). Similarly,
> `np.sum(mymaskedarray, keepdims=True)` does not respect keepdims, but it
> could work if all subclasses supported keepdims.
> I do not foresee immediate problems with adding keepdims to the matrix
> methods, except that it would be an unused argument. Modifying `np.sum`
> to always pass on the keepdims arg is trickier, since it would break any
> code that tried to np.sum a subclass that doesn't support keepdims, eg
> pandas.DataFrame. **kwargs tricks might work. But if it's permissible I
> think it would be better to require subclasses to support all the
> keyword args ndarray supports.
What is the advantage over having an error raised due to the invalid
**kwargs trick when the subclass does not support it? First sight it
seems like a far shot have a hard requirement. The transition period
alone seems hard, unless we have add magic to test the subclass upon
creation, and I am not sure that is easy to do (something like ABC
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the NumPy-Discussion