filled: 1. I don't like default fill value. It should be mandatory to supply fill value. +1
2. It should return masked array (with trivial mask), not ndarray. -1. Unless 'mask/missing/na' becomes a default in ndarray, and other basic ndarray functions know how to deal with MA seamlessly
3. The name conflicts with the "fill" method. fillmask ? clog ?
4. View/Copy inconsistency. Does not provide a method to fill values in-place. But once again, I don't think it should be the default behaviour ! A filled array should always be a copy of the initial array. Changing in place means changing the initial data, and I foresee lots of fun to find the original back. No ctrl+Z.
mask:
1. I've got rid of mask returning None in favor of False_ (boolean array scalar), but it is still not perfect. I would prefer data.shape == mask.shape invariant and if space saving/performance is deemed necessary use zero-stride arrays. You,lost me on the strides, but I agree with data.shape==mask.shape as a std
2. I don't like the name. "Missing" or "na" would be better. Once again, it's a point of view. Masked data also means 'data that I don't wanna see now, but that I may want to see later'. Like masking an bitmap/raster area. +0 for na, no for missing.
I would not object making mask read only, however. Good point. but I was more and more thinking of the opposite. I have a set of data that I group in three classes. Plotting one class is straightforward, I just have to mask the other two. Do I really want/need three objects for the same data ? Can't I just save three masks, and then run a data[mask] ?
If existing MA interface is rejected (which is likely) for ndarray, we can easily experiment with the alternatives within MA, which is pure python.
Er... How many of us are using MA on a regular basis ? Aren't we a minority ? It'd seem wiser to adapt MA to numpy, in Python (but maybe that's the XIXe French integration model I grew up with that makes me talk here...)