Closed paranoya closed 1 month ago
This made me laugh XD (shall we create an issue label for this as well?).
I like the getters idea and I am more inclined to the first option. This Friday I am attending an astropy meeting and I will try to bring up some discussion about this as well as learning about how to contribute.
In two weeks we could attempt to do the refactoring.
In principle, many (if not most/all) corrections could be applied equally well to
RSS
andCube
objects. Usually, theirintensity
andvariance
attributes are simply treated as a collection of spectra. I will not insist onspecutils.Spectrum1D
(oops, I just did ;^D), but I think both objects have many attributes and methods in common, and that should be properly capture in the architecture. What about the following options? Option 1Option 2 Instead of a common parent (
SpectraContainer
),Cube
could be a child fromRSS
and overrideget_rss_*
To be honest, I am more inclined towards Option 1, preparing for the time where other data types, such as
astropy.CCDData
(oops again ;^D) hang fromDataContainer
.