-
Notifications
You must be signed in to change notification settings - Fork 300
PI-3483: Make changes to coord_comparison private #3558
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3575,23 +3575,23 @@ def __eq__(self, other): | |
| ) | ||
|
|
||
| if result: | ||
| coord_comparison = iris.analysis.coord_comparison( | ||
| comparison = iris.analysis._dimensional_metadata_comparison( | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @stephenworsley Seems like we're baking in some indirection here, where the behaviour of our public API is now depending on the private behaviour of This means that indirectly we can change the public API behaviour of
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I don't see why this is a particular concern. It should be obvious that we wouldn't change the behaviour of the public function without very careful considering + management, and I think the public API dependence on the private function should be clear enough to any potential developer that it wouldn't happen by accident. Of course, if we make the more general private function public all such problems would go away. But IMHO that seems like a good deal more work that we just don't really need to commit to at this stage. |
||
| self, other, object_get=Cube.cell_measures, | ||
| ) | ||
| # if there are any cell measures which are not equal | ||
| result = not ( | ||
| coord_comparison["not_equal"] | ||
| or coord_comparison["non_equal_data_dimension"] | ||
| comparison["not_equal"] | ||
| or comparison["non_equal_data_dimension"] | ||
| ) | ||
|
|
||
| if result: | ||
| coord_comparison = iris.analysis.coord_comparison( | ||
| comparison = iris.analysis._dimensional_metadata_comparison( | ||
| self, other, object_get=Cube.ancillary_variables, | ||
| ) | ||
| # if there are any ancillary variables which are not equal | ||
| result = not ( | ||
| coord_comparison["not_equal"] | ||
| or coord_comparison["non_equal_data_dimension"] | ||
| comparison["not_equal"] | ||
| or comparison["non_equal_data_dimension"] | ||
| ) | ||
|
|
||
| # Having checked everything else, check approximate data equality. | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
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.
Just add a comment or docstring to explain
Cube.coords()(which is the default).Sorry, don't know how to make this really short !!
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.
@stephenworsley I don't quite understand the reason for making this private?
Wouldn't there be general utility in making this public and exposing this behaviour?
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.
@bjlittle My thinking behind making it private is that this should always serve as the most generic version of comparison for dimensional metadata. If it needs to change in the future to make it more generic, there is room to do so. To expose the new comparison behaviour, would it make sense to create specific public functions
cell_measure_comparisonandancillary_variable_comparisoninstead?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.
@bjlittle With that said, much of the output form
_dimensional_metadata_comparisonreads as coordinate specific. If this function were to be made public somehow, I think this would need to be addressed.Uh oh!
There was an error while loading. Please reload this page.
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.
Personally, I'm not convinced that we need public functionality for this.
If we do want that, then I don't like either the existing form with the magic 'object_get' keyword, or the prospect of additional specific routines for
cell_measure_comparisonandancillary_variable_comparison.Instead, I would push for a general-purpose
dimensional_metadata_comparisonroutine with a somewhat friendlier API, maybe anelement_type='coordinate'(string) keyword.But in the end, I think we can just not do that, for now.
And that is clearly less work 😈