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

Make Quantity comparisons less error prone #12

Open
llucax opened this issue Jan 15, 2024 · 0 comments
Open

Make Quantity comparisons less error prone #12

llucax opened this issue Jan 15, 2024 · 0 comments
Labels
type:enhancement New feature or enhancement visitble to users
Milestone

Comments

@llucax
Copy link
Contributor

llucax commented Jan 15, 2024

What's needed?

We need to make it as hard as possible for users to shot themselves in the foot.

Allowing == comparisons with Quantitys is generally unsafe, because it uses a float underneath.

Proposed solution

Disallow using == with Quantitys.

Ideally it should be rejected by the type system (mypy), but it should also raise an exception (or return NotImplemented if type checking is not used). If possible users should be redirected to using Quantity.isclose() instead.

Ideally isclose() should probably handle 0 (or values close to 0) specially, as documented in math.isclose.

Users can always escape this by accessing the raw float and using == with that in weird cases where == might be necessary, but that should be considered a low-level operation.

Use cases

This came up when trying to see if a battery pool is full or empty. Naturally one would do soc == Percentage(100), but this could have issues if the soc calculation has some precision issue and it is something like 99.999999 instead. But this problem is much more general than that, users should always try to think in terms of isclose() instead of strict equality with floats.

@llucax llucax added the type:enhancement New feature or enhancement visitble to users label Jan 15, 2024
@llucax llucax transferred this issue from frequenz-floss/frequenz-sdk-python Jun 26, 2024
@llucax llucax added this to the Untriaged milestone Jun 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement New feature or enhancement visitble to users
Projects
Status: To do
Development

No branches or pull requests

1 participant