-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[MNT]: Tracking issue for Numpy 2.0 transition #26422
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
Comments
Hi @ksunden! About |
To be clear, this is a maximalist "delete as much as we can" proposal to start (it proposes removing 40% of the names in the numpy namespace, though a good portion of those are dtype related things, for which moving is one of the main goals of numpy 2.0) I expect several of these to be off of this list of deletions before it is completed, and we may have to do compatibility things while we support both np 1.26 and np 2.0, e.g. (@mtsokol, I started writing this clarification before you posted... I do understand, just also wish to stay on top of what might change, and provide the feedback to you early enough for it to be useful) |
As far as I can tell, the removals have been scaled back to the point that we do not have any further changes anticipated for numpy 2.0 (at least from this list) that have not been PR'd (recarray being the last open one) @QuLogic having looked this over I may amend my thoughts regarding backporting the changes we have done to the 3.7 branch/pinning 3.7.3 to I will go ahead and close this as all items are either no-action or already have a PR tracking them individually. |
Summary
This is a tracking issue for all of the things that (will) need to change for numpy 2.0
xref numpy/numpy#24306
Edit 2023-08-03: Updated to list according to numpy/numpy#24306 (comment)
NaN
andInf
fall into the "tentative" category, which is to say possibly removed, but not fully decided.Edit 2023-08-31: Updated to list according to most recent numpy list
Proposed fix
List of functions affected
Most of the changes are relatively simple namespace swaps... but if we wish to be backwards compatible, may require some finagling in the interim
Some of these we may wish to advocate with numpy to keep, particularly some of the things we use that numpy would say "use scipy" for, as I don't think we are prepared to take on scipy as a dependency.
Some of them (e.g. hanning/blackman window functions) it may be better to just vendor or deprecate mlab functions/change examples to avoid using them (we already vendor GaussianKDE...)
Removed from top level, kept/moved to np.linalgnp.cross
np.inner
np.outer
np.transpose
Removed from top level, moved to np.dtypesnp.iscomplexobj
np.isreal
np.isscalar
np.issubdtype
np.min_scalar_type
np.promote_types
Removed from top level, moved to np.rec
np.recarray
MAINT: Reflect changes fromnumpy
namespace refactor Part 5 #26664Removed from top level, kept in np.index_tricksnp.c_
np.r_
Removed in favor of alias/similar func
np.Inf
(almost certain to be removed, trivial to replace) Remove soon to be deprecated nan/inf aliases #26458np.inf
np.NaN
(almost certain to be removed, trivial to replace) Remove soon to be deprecated nan/inf aliases #26458np.nan
np.array_split
np.split
np.in1D
MAINT: Numpy 2.0 deprecations for row_stack and in1d #26566np.isin
np.nanmin/max
np.max(..., nan='ignore')
or similar instead of separate, parallel funcsnp.polyfit/polyval
np.polynomial.Polynomial.fit
np.roots
np.rowstack
MAINT: Numpy 2.0 deprecations for row_stack and in1d #26566np.vstack
Fully removed (?)np.isfortran
np.putmask
a[mask]=b[mask]
, but doesn't do repeating behavior, so would have to verifnp.s_
Possibly renamed, but not settlednp.ix_
The text was updated successfully, but these errors were encountered: