Iris: Constraint equality?

[rcomer]

This may be a fairly niche requirement but...

Sometimes we write functions that return iris.Constraint instances. It is not obvious how to write unit tests for these functions, as you can't check whether two constraints are the same. How easy would it be to implement constraint equality?

[nhsavage]

I would also like to be able to do this.

[pp-mo]

At a basic level, I think this ought to be fairly simple.
I think there are only a few classes for which a basic __eq__ needs to be written, all in iris._constraints.

However I note that a local discussion on this (Yammer) has gone a bit off-piste on ways to identify equivalent lambda functions, which is pretty hard-core !!
It does point up a real problem though: constraints on coords, attributes and names can all be provided with callable functions instead of values to match, in which case it won't be possible to do equality matching (an "identical" definition won't give something "equal").
However, I _think_ that we could make this work for constraints based on value matching.

[rcomer]

Thanks @pp-mo for giving this some thought. For the callable-function case, I wonder if it's possible to get hold of the function from the Constraint instance. Then our testing approach could be something like:

• Assert constraint works on time coordinate with a function.
• Given this list of datetimes, assert said function produces this expected list of booleans.

[rcomer]

list of datetimes

Or rather, a list of Cells, I guess....

[pp-mo]

Hi @rcomer @nhsavage
Does #3749 cover your needs, that prompted this ?

---

however...

@rcomer the callable-function case,

I really don't think we can or should do this.
A function is a black box, and we can't check whether it does the same as another function, only (at best) whether it is the same for specific test values. But those totally depend on the cubes, and I don't think we have any sensible way of generating testpoints in the general case anyway. And for coords, it could be using the bounds too ...
Is this a deal-breaker ??

[rcomer]

Thanks @pp-mo

Here are the cases I know of in our group's projects. I've had a play with the non-callable-function ones and your branch and, as far as I can see, the equality behaviour works nicely.

1. stash_constraint ✔️

2. fields.py has
   a. pp_field_constraint unfortunately this one uses a lambda 😞
   b. grib_field_constraint ✔️
   c. name_field_constraint ✔️

3. GSDSCube.__constrain_starts_or_years This one also sometimes uses a lambda though I guess it could use a PartialDateTime instead.

@rcomer the callable-function case,

I really don't think we can or should do this.

Sorry, I don't think I was clear there. I meant that, if the function was exposed as a public attribute on the Constraint, the writer of the user code/tests could write tests directly for that function. They should know what the typical/expected input values are for their project. Having said that, I guess said writer could supply a typical cube or cubelist and go ahead and use the constraint on it for the same result. Hmmm.

Is this a deal-breaker ??

Definitely not! Being able to test some cases is better than being able to test no cases!

[nhsavage]

I think that this will meet my requirements. Thanks

[trexfeathers]

We're going to take a look at this for v3.1