ENH: implement a base comparison operator (__eq__) for NDData

[neutrinoceros]

Description

This pull request is to address #11648

Actually it's not completely clear to me wether there's actually a consensus on doing this in any way or form:

• the issue didn't receive any attention (yet)
• APE7 explicitly warns that "The NDDataBase class should not define any arithmetic operations, which are impossible to generalize" (though it doesn't specify that NDData shouldn't get a __eq__ so the possibility seems open)

I'm opening this at an early stage in hopes to get the discussion going, or that the PR be rejected before it consumes too much time.
I'm aware that if a consensus is to be reached, most likely we'll want to implement comparison on more than just data, mask and unit, but that's also open to discussion: are there any attributes in NDData that we should not compare in __eq__ ?

If this is greenlit and more attributes indeed need to be compared, I'll probably need to upgrade the test using hypothesis to improve coverage.

Fixes #11648

• By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

[github-actions]

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

[github-actions]

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

[bmorris3]

Equality should ensure that every attribute is "equivalent". Some challenges:

• there isn't an obvious definition of "equivalence" for units – do we allow the user to check for equivalence via strict equivalence (km == km), physical type (AA ~= km), with (our) equivalencies (AA ~= Hz)?
• NDData can have WCS attributes. Is there any functional WCS equivalence check that generalizes well to any APE-14 compliant WCS representation?
• there isn't an equality built-in for NDUncertainty classes yet, but I'd argue that if the uncertainties are different, the NDData objects are not equivalent. We could implement that as part of this PR, but that will take some care, since some NDUncertainty subclasses can be equivalently represented as others.
• how would we want this to behave for subclasses? Should we ever let an instance of CCDData == an instance of NDData, when CCDData may also have a flags?

[pllim]

Sounds like a few cans of worms need to be emptied for this to go forward? 😬

Is there any functional WCS equivalence check that generalizes well to any APE-14 compliant WCS representation?

Maybe @mcara or @nden know.