Ouranosinc / xclim / 6614076758

90%

main: 92%

push

github

Fix data flags var name generation (#1507)

<!--Please ensure the PR fulfills the following requirements! -->
<!-- If this is your first PR, make sure to add your details to the
AUTHORS.rst! -->
### Pull Request Checklist:
- [ ] This PR addresses an already opened issue (for bug fixes /
features)
- This PR fixes a issue raised in private communication by @RondeauG
- [x] Tests for the changes have been added (for bug fixes / features)
- [x] (If applicable) Documentation has been added / updated (for bug
fixes / features)
- [x] CHANGES.rst has been updated (with summary of main changes)
- [x] Link to issue (:issue:`number`) and pull request (:pull:`number`)
has been added

### What kind of change does this PR introduce?

Changes how the data flags variable names are generated.

In the previous version, every kwargs was sent to `str2pint`. We were
relying on a `try: except` to catch those kwargs that weren't
quantities. This had the caveat of requiring an explicit list of
possible errors. @RondeauG had a case where `op='>='` was triggering a
`ValueError`, which wasn't listed.

I changed this "implicit" parsing to an "explicit" one:
- Data flags declare the variable name as a templated string.
- Parameters are iterated through and handled according to their
"InputKind"
- "Quantified" inputs are handled as before, but all others are passed
as-is.

This required:
- Changing the registering decorator to accept a templated string
argument
- Correctly annotating the inputs, which lead to adding missing
thresholds to the declared units

### Does this PR introduce a breaking change?
Yes, I made the arbitrary choice of changing how we stringify the minus
sign:

```
Input thresh : -5.1 mm
Template : "values_greater_{thresh}"
Before : "values_greater__minus_5point1"
This PR: "values_greater_minus5point1"
```
However, I don't think this will affect many projects.

### Other information:
@RondeauG , could you try this... (continued)

42 of 43 new or added lines in 1 file covered. (97.67%)

8457 of 9339 relevant lines covered (90.56%)

4.37 hits per line