Skip to content
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

Iris interface handles standard constructors enabling unit tests #709

Merged
merged 4 commits into from
Jun 9, 2016

Conversation

philippjfr
Copy link
Member

This PR allows the iris interface to handle the standard tuple and dict based constructors making it equivalent to the grid interface. This means all the unit tests, except for aggregation and sampling (which are not yet implemented), can be shared across the two interfaces.

@philippjfr philippjfr changed the title Iris handles standard constructors enabling unit tests Iris interface handles standard constructors enabling unit tests Jun 4, 2016
@philippjfr
Copy link
Member Author

Fixes various inconsistencies and adds better coverage. Ready to merge.

self.data_instance_type = iris.cube.Cube
self.init_data()

def test_dataset_add_dimensions_values_hm(self):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you are doing this to disable some of the inherited tests. A docstring explaining why these tests are not enable would be good...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sounds good. They should eventually be remove once those methods are implemented.

@jlstevens
Copy link
Contributor

Looks good and good to support those constructors. My only worry is won't changing the way it does inclusive/exclusive bounds be an issue for backwards compatibility? Perhaps I'm missing something...

@philippjfr
Copy link
Member Author

My only worry is won't changing the way it does inclusive/exclusive bounds be an issue for backwards compatibility?

Backwards compatibility for the Iris backend? I guess so, but it was a bug since it was inconsistent with the other interfaces.

@jlstevens
Copy link
Contributor

Ok, as long as that is clear. I agree consistency is more important, especially as this interface is new.

I'm happy to merge now, although maybe you might like to implement my self.epsilon suggestion? Defining something called epsilon helps make it clear that all you want is a small increment to include something in the bounds that would otherwise be excluded.

@philippjfr
Copy link
Member Author

I'll do that quickly in addition to adding a comments about the disabled tests.

@philippjfr
Copy link
Member Author

Done. Ready to merge.

@jlstevens
Copy link
Contributor

Looks good. Merging.

@jlstevens jlstevens merged commit 16d97f4 into master Jun 9, 2016
@jlstevens jlstevens deleted the iris_constructor branch July 12, 2016 22:56
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants