numpy 2 compat: tests failing with default print options

[neutrinoceros]

We currently have about 400 tests that don't pass against numpy 2.0 if we remove the following line

astropy/astropy/conftest.py

Line 28 in b2e38be

np.set_printoptions(legacy="1.25")

90% of the solution is already isolated in #16416, and we can probably extract backportable solutions for the other 10% from #15065.

I'm seeing ~400 failures (doctests included) on main, 90% of which are resolved by #16416, but not all of what's left are doctests, which, as discussed in #15095, are not critical and can be post-poned to after numpy 2.0.0 final comes out (supposedly this would be for astropy 7.0.0)

Everything that's not a doctest, and not already fixed in #16416, should probably be addressed for 6.1.1

Affected modules:

• coordinates (1 test) TST: adapt a coordinates test to numpy 2 #16427
• io.fits (4 tests) BUG: fix compatibility with numpy 2 in diff reports (io.fits, utils) #16426
• io.votable (15 tests) BUG: fix bugs in io.votable related to numpy 2's representation of scalars #16442
• table (7 tests) TST: adapt table representation tests to numpy 2 #16433
• utils (2 tests) BUG: fix compatibility with numpy 2 in diff reports (io.fits, utils) #16426 and BUG: fix bugs with how masked structured arrays were represented with numpy 2 #16443

I expect solutions were already found by @mhvk in #15065, so it's mostly a matter of making targeted cherry-picks.

[neutrinoceros]

note for later: I think one of the failures we got in utils is showing an discrepency between how masked arrays are represented (repr) with respect to ordinary arrays in numpy 2.0. This may be something to report upstream but I need to dig further.

[mhvk]

Maybe an idea is to merge #15065 for main, and then backport pieces of that? In any case, it seems sensible for me to rebase that...

[neutrinoceros]

Actually what I'm finding out thusfar is that the failures I'm pointing to in this issue are not resolved by #15065, and require their own solution. Since they are related but separable problems, I don't think we need to discuss this here.

[mhvk]

@neutrinoceros - in rebasing #15065, I found test failures with pandas which are not representation-related. Are those among those you are thinking of? Also, if bottleneck is installed, some representations from sigma clipping look different...

[pllim]

Re: #16423 (comment)

Nevermind, I just saw #15095 (comment)

[neutrinoceros]

re #16423 (comment):
I'm now thinking the bug is actually on our side, specifically in MaskedFormat.__call__, but I don't have time to fix it just now. VOTable failures are also a puzzle and are possibly related, so I think utils.masked should be the next priority. I'll come back to it later today if time allows.

[neutrinoceros]

Upon a closer look at #15065, it seems that it already has solutions for both utils (d84166e) and votable (940e5e7).
Unless we changed our minds about waiting for numpy 2.0 final to merge #15065, I think these ought to be cherry-picked and backported. What do you think @mhvk ?

[mhvk]

I actually wondered about whether we shouldn't just merge #15065 for main, and then backport the commits that do not have to do with the documentation (i.e., docs for 6.1 stay at numpy < 2.0 format). Though perhaps effectively that is the same amount of work...

[neutrinoceros]

I think it's very much a comparable effort and not a big undertaking for us two, but the cherry-picking approach should make reviewing easier. If you agree to it, it shouldn't take me long to finish cherry picking the user-facing parts (only two more PRs).

[mhvk]

OK, let's go that route - then #15065 will probably get in when numpy 2.0 is out (just saw rc2 was released).

[neutrinoceros]

Done with #16442 and #16443

[neutrinoceros]

numpy 2.0 has a release date: numpy/numpy#24300 (comment)

I'd recommend merging the remaining PRs related to this issue and cutting a 6.1.1 release before june 16th
FYI @astrofrog @saimn @mhvk @pllim

[pllim]

So is it just #16427 and #16433 left?

[neutrinoceros]

Yes !

[pllim]

When they are all in, do we need a follow-up issue to get rid of without_legacy_printoptions in the future? Or do we already have such issue?

[neutrinoceros]

I don't expect it to get in the way of anyone so it should be very low priority, but I do have a personal reminder to clean it up when the time comes.
That said, your phrasing seems to imply that not having an issue isn't an option, so let me open one now :)

update: #16491

[pllim]

imply that not having an issue isn't an option

Well, I can't arrest you or anything... 😸 Thanks for opening the issue! It is good to have it out in the open to show people we're aware of it.

[neutrinoceros]

I can't arrest you or anything

Let's call it making me an offer I can't refuse 🤌🏻

[neutrinoceros]

Alright, everything was merged, let's close this ! thanks !