I think there is some thinking to do about how we would subclass. I raise that as there is an example given as Spectrum1D, yet I think lots of spectral functionality can be done without regard to whether it is 1D, 2D, or 3D. And the same spectral capability could coexist with image capability (e.g., in the 3D case). I'd like to avoid having to cover all possible combinations of things in these subclasses (one could almost look at this as cases for mix-ins)

@perrygreenfield - I agree that we have to think about how to avoid having Spectrum1D/2D/3D and Image duplicate too much code. Since Spectrum1D, Spectrum2D, and Image can be represented as Spectrum3D with one element along specific dimensions, we may be able to make them re-use Spectrum3D with on-the-fly slicing. However, I would say this is beyond the scope of the APE because there are also other kinds of NDData, for example 3d spatial volumes, that are distinctly separate.

Regarding the slicing, the way you worded it is what I meant - I will try and clarify this. In fact, the WCS class in astropy already supports basic slicing.

I agree with the details of subclassing being beyond the scope. The main point is to avoid examples that imply how it will be done (e.g., Spectrum1D).

@perrygreenfield - ah yes, I see what you mean. I'll fix that.

I've left a few comments inline.

If we do keep this modified NDData in the Astropy core, it would be good if it's rock-solid by the time of the Astropy 1.0 release.
Are there other existing data classes besides the ones in ccdproc and specutils that could / should use this to get some real world testing (maybe spectral-cube) and functions such as the ones in astropy.convolution or imageutils to make sure that what is described here really works well and give code re-use benefits in practice?

I mean this is what happened two years ago ... an NDData class was quickly introduced into the Astropy core without having sub-classes and functions using them with real-world usage and then it was realised that in practice it causes problems.

Maybe this could simply be mentioned in a sentence here: before the Astropy 1.0 release we encourage X, Y, Z (the classes and functions we have in mind) to use this and give feedback?

Not sure where best to insert this, but the new base NDData should not include the methods that make it act like a numpy array (__array__ and __array_prepare__), so that the sole way to get data out is through NDData.data. This is mostly because generalizing mask to something that is not an array makes it much less straightforward to convert to a numpy masked array.

Subclasses might provide these methods (it is convenient in CCDData, for example) but not the base class.

@cdeil - you raise good points. I think that certainly before we actually decide on this we should demonstrate some real-life examples using the proposed decorator and functions. I think that this is what was lacking until now - actual applications!

Sorry, I missed that there was a PR for this. I've been making my comments in e71e6e0 (though it looks like GitHub is helpfully copying them over here automatically).

I agree with the details of subclassing being beyond the scope. The main point is to avoid examples that imply how it will be done (e.g., Spectrum1D).

I actually think this APE would strongly benefit from an example of how it would be done. For example an at least partially working example of a CCDImage class or something of the like (or maybe something simpler). I think that in addition to the actual technical aspects, one reason NDData hasn't taken off is that Astropy hasn't included an example of how it would be used. I think that if not this APE itself, there should be a companion APE for at least one NDData subclass that would be simple enough to serve as a pedagogical example, but also interesting enough to be useful (even if just as a subclass of more specific types).

(Agreed though that "Spectrum1D" much less "SpectrumAnyD" is not a good example.)

Seems like my last comment mirrors a lot of @cdeil's feelings about it to.

Though to be clear I'm in favor of this APE in general.

Also I agree with @mwcraig that there probably should not be a guarantee of direct compatibility with ndarray (i.e. via __array__, etc.) although it should be encouraged where possible.

@astrofrog -- though I'd bump this... is there any reason not to make a PR on the main APE repo and ask for feedback on astropy-dev?

@astrofrog -- I should add that I can rough out an example Image subclass if you want...

@perrygreenfield @cdeil @mwcraig @embray - thanks for all your comments so far! I'm going to close this and will open a PR on the real APE repository to open it for full review.