MAINT: *sctype* replace NumPy 2.0 #18841
Conversation
* replace `*sctype*` NumPy usage per numpy/numpy#23999 and NEP52 in preparation for NumPy 2.0 * there seem to be straightforward replacements that still pass the testsuite in all cases * `git grep -E -i "sctype"` is clean on this branch (only present in comments for clarity where needed) * there may be better canonical ways to do some of these things in the future, though considerable confusion remains per numpy/numpy#17325 * `UMFPACK`-related changes were not tested locally (wasn't particularly friendly for PyPI-based setup/venv) [skip circle]
| @@ -165,7 +165,7 @@ def _copy_array_if_base_present(a): | |||
| """ | |||
| if a.base is not None: | |||
| return a.copy() | |||
| elif np.issubsctype(a, np.float32): | |||
| elif issubclass(a.dtype.type, np.float32): | |||
There was a problem hiding this comment.
Is this now a canonic NumPy way of checking if an array is single-precision? In the same like, is the way to check if an array is floating-point (as opposed to integer or complex), issubclass(a.dtype.type, np.floating)?
Asking because there is also np.issubdtype --- would be great to actually know what's the preferred way now that numpy 2.0 is on the horizon
There was a problem hiding this comment.
Yeah, not sure, but I think folks smarter than I debate this type of stuff in the issue I linked?
There was a problem hiding this comment.
Ah indeed. Reading comprehension issue on my side, sorry about that!
Agreed, let the bright minds of numpy converge to something, we'll happily follow. The current spelling is certainly better than issubsctype, so +1 from me.
(I probably could have a tiny preference for np.issubdtype but it's not worth the churn).
|
CI is happy, changes LGTM. Thanks Tyler, in it goes. |
replace
*sctype*NumPy usage per Tracking issue: Python API cleanup for NumPy 2.0 (NEP 52) numpy/numpy#23999 and NEP52 in preparation for NumPy 2.0there seem to be straightforward replacements that still pass the testsuite in all cases
git grep -E -i "sctype"is clean on this branch (only present in comments for clarity where needed)there may be better canonical ways to do some of these things in the future, though considerable confusion remains per ENH: add a canonical way to determine if dtype is integer, floating point or complex numpy/numpy#17325
UMFPACK-related changes were not tested locally (wasn't particularly friendly for PyPI-based setup/venv)[skip circle]