-
-
Notifications
You must be signed in to change notification settings - Fork 53
Simplify NDCube.to_nddata #892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
unit=True, | ||
meta=True, | ||
psf=True, | ||
nddata_type=NDData, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only remaining question is if we want to add a copy=False
kwarg here which changes the copy behaviour to be copy by value rather that the default of copy-by-reference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid that, as currently written, I don't see this as an improvement to what has already been merged for a few reaons.
First, we can't use bool
to represent attributes that need to be copied because True
is a valid user-defined value for mask
.
Secondly, what we currently have allows users to convert to an NDCubeBase
subclass while carrying over extra_coords
and global_coords
. I can imagine this being useful, especially if users want to change a value during the conversion, e.g. uncertainty.
Thirdly, if to_nddata
is being used between NDCubeBase
subclasses with additional attributes/kwargs, then this line that has been removed in this PR, captures those. By removing it, this code now unnecessarily would cause such cases to break. Alternatively, it unnecessarily requires maintainers of NDCubeBase
subclasses to over-ride this method.
Additionally, I don't understand the depth of the objection to the to_nddata
method. I agree that it's not the most elegant philosophically speaking. But as far as I can see, it is the most elegant practical solution to a problem that our users need solved.
data=True, | ||
wcs=True, | ||
uncertainty=True, | ||
mask=True, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't use mask=True
here as True
is a valid user input for mask
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, that's so freaking stupid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The solution to this is that the one user who wants to do this uses np.True_
rather than True
to set the whole mask to be a single boolean.
if key in inspect.signature(nddata_type).parameters.keys()} | ||
**kwargs} | ||
# If any are True then copy by reference | ||
user_kwargs = {key: getattr(self, key) if value is True else value for key, value in user_kwargs.items()} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
user_kwargs = {key: getattr(self, key) if value is True else value for key, value in user_kwargs.items()} | |
user_kwargs.update(kwargs) | |
nddata_sig = inspect.signature(nddata_type).parameters.keys() | |
user_kwargs = {key: value for key, value in user_kwargs.items() if key in nddata_sig and value is not COPY} | |
all_kwargs = {key.strip("_"): value for key, value in self.__dict__.items() if key in nddata_sig} | |
all_kwargs.update(user_kwargs) |
eugh, I still don't think breaking this truly weird case is worth the extra complexity.
It doesn't break this or any other use cases it just means you have to opt-into copying these things. See the test and the new example in the docstring.
see above.
I think we are conflating too many tasks into one method which makes the API and the implementation too complex both for us to maintain and for users to understand. I think we need to de-scope this thing. I'd almost rather just get rid of |
I couldn't take it.