DEP: Deprecate np.find_common_type#22539
Conversation
Rather, use `result_type` instead. There are some exceedingly small theoretical changes, since `result_type` currently uses value-inspection logic. `find_common_type` did not, because it pre-dates the value inspection logic. (I.e. in theory, this switches it to value-based promotion, just to partially undo that in NEP 50; although more changes there.) The only place where it is fathomable to matter is if someone is using `np.c_[uint8_arr, -1]` to append 255 to an unsigned integer array.
The function uses the numeric scalar common dtype/promotion rules. These are subtly different from the typical NumPy rules defined by `np.result_type`. Mainly, there is no good reason to have two subtly different rules exposed and `find_common_type` is less reliable, slower, and not really maintainable when it comes to NEP 50.
Unfortunately, the notes for the `np.r_` change is rather long even though it is not a change I expect to hit a whole lot of users...
c4e4bd7 to
3c15610
Compare
rossbar
left a comment
There was a problem hiding this comment.
I'm +1 for the deprecation, especially given the changes proposed in NEP50.
FWIW I grepped other scientific Python libraries and did notice a few instances in e.g. scikit-learn (3) and astropy (1), but they were all of the scalar_types=[] variety, so replacing with result_type should be straightforward.
| @@ -0,0 +1,24 @@ | |||
| ``np.find_common_type`` is deprecated | |||
There was a problem hiding this comment.
This is a lot of info for a release note but then again the situation is complicated. I'm +1 for leaving the info in the release notes instead of the docs proper since this is a deprecation and the complexity will be reduced in the future.
|
The pandas PR highlights two small changes I didn't notice:
Seems unlikely many will run into this (or even prefer no error), but pandas seems to... |
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>
That is, once the NEP 50 transition happens
43e239a to
1ad0166
Compare
|
We discussed this at the triage meeting and decided to wait until after 1.24 is out to merge this. |
|
This would close #21703, could someone link it in the OP or "Development"? |
|
close/reopen |
|
@seberg Be good to finish this up, |
|
I think the circleci failure will go away with a rebase. |
Remove `find_common_type` export from `numpy/__init__.pyi`.
|
Thanks Sebastian. |
|
Thanks for fixing this up! I hope its not annoying to adapt to without gh-22568, although I guess chances are mainly/only pandas notices, so maybe that is OK if it is? |
The function uses the numeric scalar common dtype/promotion rules.
These are subtly different from the typical NumPy rules defined by
np.result_type.Mainly, there is no good reason to have two subtly different rules
exposed and
find_common_typeis less reliable, slower, and not reallymaintainable when it comes to NEP 50.
Closes #21703.
The function was used once within NumPy, and that is in the AxisConcatenator which implements
np.r_andnp.c_. I replaced the occurrence there fornp.result_typewhich mildly changes behavior in some odd cases like:(cases where unsigned arrays are mixed with signed scalars (not 0-D arrays even), and cases which currently lead to overflows during casts.)
Closes gh-21703