Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[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

Closed
4 of 5 tasks
ksunden opened this issue Jul 31, 2023 · 3 comments
Closed
4 of 5 tasks

[MNT]: Tracking issue for Numpy 2.0 transition #26422

ksunden opened this issue Jul 31, 2023 · 3 comments

Comments

@ksunden
Copy link
Member

ksunden commented Jul 31, 2023

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)

  • Note that almost all (aside from NaN and Inf 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.linalg

  • np.cross

    • used in proj3d.py, art3d.py
  • np.inner

    • used in test_patches.py
  • np.outer

    • used several places
  • np.transpose

    • used in several places, often with list inputs

Removed from top level, moved to np.dtypes

  • np.iscomplexobj

    • used in mlab.py
  • np.isreal

    • used in cbook.py, bezier.py, test_mlab.py
  • np.isscalar

    • used in _axes.py, cbook.py, figure.py
  • np.issubdtype

    • used in several places, usually in conjuction with other things that are moving
  • np.min_scalar_type

    • used in colors.py
  • np.promote_types

    • used in stackplot.py, colors.py

Removed from top level, moved to np.rec

Removed from top level, kept in np.index_tricks

  • np.c_

    • used in angle_annotation example only
  • np.r_

    • used in test_agg.py and demo_agg_filter.py (example)

Removed in favor of alias/similar func

Fully removed (?)

  • np.isfortran

    • used in test_triangulation.py
  • np.putmask

    • used in colors.py
    • may be replaced by a[mask]=b[mask], but doesn't do repeating behavior, so would have to verif
    • comment supports the idea that a simple replacement is possible
  • np.s_

    • used in cbook, 3dplot example

Possibly renamed, but not settled

  • np.ix_
    • used in _triinterpolate.py, test_image.py
@mtsokol
Copy link
Contributor

mtsokol commented Jul 31, 2023

Hi @ksunden!
Just a heads up: The discussion for refactoring main NumPy namespace to be done in NEP 52 just started, and the list in numpy/numpy#24306 is WIP and far from final - I would assume that the scope of changes will evolve.

About scipy dependency - the issue is meant discuss what should be present in top NumPy namespace. The functionalities are not meant to be removed completely from Numpy but only from np.*. These functions will be still available in submodules. In comments I changed use scipy... to also available in scipy... as that was the message that I wanted to enclose.

@ksunden
Copy link
Member Author

ksunden commented Jul 31, 2023

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)

@ksunden
Copy link
Member Author

ksunden commented Aug 31, 2023

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 <2.0, as while we cannot guarantee that there will be no further changes needed, we are on firmer ground with the guess that there will not be as much change needed, and thus I think we can probably backport what we have (maybe without the recarray example changes, possibly pin the 3.7 doc build (but not install requires) to <2.0)

I will go ahead and close this as all items are either no-action or already have a PR tracking them individually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants