fix:numpy 2.2.2 type compatibility issue #2616
Conversation
|
Please add a pinning of numpy in the meta.yaml so that users which update don't stay with the wrong version. |
localbuild/meta.yaml
Outdated
| @@ -86,6 +86,7 @@ requirements: | |||
| - flask-login | |||
| - pysaml2 | |||
| - libxmlsec1 # [not win] | |||
| - numpy <2.0 | |||
There was a problem hiding this comment.
the fix is for the next major 10.0.0, so we want here >=2 and also the codechanges needed.
|
@anj20 please rebase to develop, it is currently out. of sync, you maybe need to sync your develop beforehand. Merge attempt failed |
I have rebase. |
| @@ -133,7 +133,7 @@ def omega_to_w(omega, p, t): | |||
| (32 * units.km, 228.65 * units.K, 868.019 * units.Pa, -0.0028 * units.K / units.m), | |||
| (47 * units.km, 270.65 * units.K, 110.906 * units.Pa, 0 * units.K / units.m), | |||
| (51 * units.km, 270.65 * units.K, 66.9389 * units.Pa, 0.0028 * units.K / units.m), | |||
| (71 * units.km, 214.65 * units.K, 3.95642 * units.Pa, float("NaN") * units.K / units.m) | |||
| (71 * units.km, 214.65 * units.K, 3.95642 * units.Pa, np.nan * units.K / units.m) | |||
There was a problem hiding this comment.
Generally recommended is to use np.nan when working with NumPy arrays and float("NaN") when working with built-in Python types.
This is likly the reason why May has used float("NaN") here.
It is not the only place where we have the string notation. When that gets changed then always.
There was a problem hiding this comment.
i think float("NaN") is used only once in the develop branch.
Do I need to revert back the change in this file ?
There was a problem hiding this comment.
you maybe need to do a regex lookup, I think I mentioned on slack, demodata
There was a problem hiding this comment.
I asked @joernu76 about the changes here, but no answer to that question yet.
|
we see failing tests because of read timeout |
Purpose of PR?:Resolves numpy 2.2.2 compatibility issue by replacing deprecated float_ type with float64
Fixes #2615
Does this PR introduce a breaking change?
No, this is a minor type compatibility fix that should not break existing functionality
If the changes in this PR are manually verified, list down the scenarios covered::
Checklist:
<type>: <subject>