MNT: more compatibility with NumPy 2.0 - #15235

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

pre-commit.ci autofix

Now we're hitting this but I am not sure how to respond to it:

• API: Update lib.nanfunctions namespace numpy/numpy#24536

Do we simply update the imports or we are not supposed to touch this now?

astropy/utils/masked/__init__.py:10: in <module>
    from .core import *
astropy/utils/masked/core.py:25: in <module>
    from .function_helpers import (
astropy/utils/masked/function_helpers.py:1077: in <module>
    for nanfuncname in np.lib.nanfunctions.__all__:
numpy/lib/__init__.py:87: in __getattr__
    raise AttributeError("module {!r} has no attribute "
E   AttributeError: module 'numpy.lib' has no attribute 'nanfunctions'

And then

AttributeError: `np.unicode_` was removed in the NumPy 2.0 release. Use `np.str_` instead.

😩

Oh dear, np.float_ too? Just how many more in one weekend?

p.s. Also added a commit that removes the use of np.float_ as an alias of np.float64.

Arrgg, I should have guessed given np.float_ being removed - of course the other aliases are removed too. I'll push a further fix...

That is the plan but looks like skyfield now gives trouble.

Was np.float_ never deprecated? I feel like if it was, we would have caught it and handled it before it breaks everything like this.

Gonna take a few hours for the exotic archs to finish running. I'll check back later.

Oh, no. A new one?

AttributeError: module 'numpy.lib' has no attribute 'function_base'

Oh, no. A new one?

Maybe it's somewhat new, but not necessarily, the latest wheel is 12hr old, so should have been used in CI here for a while now), but it might have been hidden by the other errors.

Alas, I ran out of time today, will have to revisit tomorrow unless @mhvk get to it (again) first.

BTW, thanks for the clean up this morning, @mhvk !

Am travelling today, so maybe you'll get to it first... And, yes, lots of renaming happening, to indicate things are private... But I think it is a one-time only reorganization...

Everything is green now except RTD that somehow killed itself. I restarted it. 🤞

I am not sure about changing devdeps to pull only "tests" instead of "tests_all" but nothing we can do about that right now if we want this in, so I'll open follow-up issue for that one (#15242).

codecov complain is unavoidable because we don't check coverage for the numpy>=2 routes.

@pllim I've opened a PR addressing the Windows issues in pllim#6, but it is not running the CI there, and I have no access to either a Windows or 32 bit system to make any tests myself.

Thanks, @dhomeier . I want to kick off the dev wheel for astropy, so I am going to merge this. Can you please turn your branch into a PR here (instead of to my fork) after that? I think we need to think about why win32 emit different warnings now. Is there some real bug we have to fix?

Thanks; don't know it it's a bug or what the Windows version is actually reading from that.
For investigating on a Windows system outside of pytest in principle it should suffice to run

import warnings
from astropy.io import ascii
from io import BytesIO
StringIO = lambda x: BytesIO(x.encode("ascii"))

warnings.resetwarnings()
x = ascii.read(StringIO("-1799E+305 0.2e-323 5200e-327"), format='no_header', fast_reader={"use_fast_converter": False})
warnings.resetwarnings()
y = ascii.read(StringIO("0." + 307 * "0" + "1"), format='no_header', fast_reader={"use_fast_converter": False})

and then check the number of warnings and the content of tables x and y.

Alas, pytest is very broken on my Windows env and I don't have time to deal with it. I don't see this problem on WSL2. 😿

Alas, pytest is very broken on my Windows env and I don't have time to deal with it. I don't see this problem on WSL2. 😿

Yes, someone with access to a Windows machine would have to run that just manually, but if they all behave different, that might not give us much info anyway...

@bsipocz , new dev wheels should be uploaded already. Please let me know if you cannot access them. Thanks!

Nope, they work, I restarted everything and CI is passing now.