Check for and prevent initialization of NDData with Quantity

[mwcraig]

This PR simply raises an error if you try to initialize NDData or StdDevUncertainty with a Quantity (see #2374)

Once I know which release this is targeted for (if any--it may be completely the wrong way to go) I'll add a changelog entry.

I could, if desired, do something a little more sophisticated (and perhaps more sensible) than this, though I don't think what is below is a long-term solution:

• Initializing NDData with a Quantity could set the NDData.data (as a numpy.ndarray) and NDData.unit
• Initializing StdDevUncertainty with Quantity could convert that quantity to the units of StdDevUncertainty.parent_nddata then set StdDevUncertainty.array with the result, raising an error if parent_nddata is None.

[embray]

Seems okay to me for the time being.

[astrofrog]

@mwcraig - can you rebase this?

[mwcraig]

This is good to go

[astrofrog]

I kind of like the alternative you are suggestion to allow a quantity to be passed and do the right thing. @eteq, what do you think?

[mwcraig]

A longer-term change would be to allow (but not require) .data to be a Quantity and have .unit and perhaps the other properties have the .data object take care of those properties. A similar approach could be used to let numpy deal with the masking--allow (but again, not require) .data to be a masked array, and have NDData's mask defer to it.

Haven't really thought this through (and probably shouldn't until ccdproc is closer to ready for some external eyes), but the implementation of, say, mask, might look something like this:

def mask(self):
    try:
        return self.data.mask
    except AttributeError:
        return self._mask

[mwcraig]

To clarify, if you want the simple ability to set NDData with a Quantity in a sensible way, I can do that in the next couple of days.

[eteq]

I agree with @astrofrog that this "simple ability" would be a very useful thing - that is, you can give a Quantity to NDData either as the value or the uncertainty, and have it behave the way @mwcraig suggests in the above bullet points.

I think for the longer-term, we either don't want to use Quantity at all internally in NDData, or always use it - e.g. NDData.unit could just behave like the mask example you gave above. But to do that right we need to have the option of masked quantities, so I think at least until then we want to keep the internals of NDData and Quantity separate.

[mwcraig]

@eteq @astrofrog -- I put in the ability to initialize with a Quantity. Doing that for the uncertainty is messy because the uncertainty needs to be created before, and independently of, its associated NDData object. I got it to work by adding a ._unit attribute to StdDevUncertainty.

I decided that it was OK to use an uncertainty without units for a NDData object with units (that was the current behavior anyway) but that using an uncertainty with units for a NNData object without units should raise an error.

[eteq]

I think this behavior all makes sense and looks good to me, @mwcraig - can you update the CHANGES.rst to reflect what it's now doing?

@astrofrog, look good to you other than that?

[eteq]

I think this behavior all makes sense and looks good to me, @mwcraig - can you update the CHANGES.rst to reflect what it's now doing?

@astrofrog, look good to you other than that?

[astrofrog]

👍

[eteq]

Looks good. Merging!