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
Adjust to numpy dev scalar format #15065
base: main
Are you sure you want to change the base?
Conversation
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.
|
👋 Thank you for your draft pull request! Do you know that you can use |
The diff looks much simpler than I anticipated. Thanks! 🤞 |
Well, the main diff from the docs is not yet in there... |
If #15096 goes in first, that PR also has to be reverted here. FYI. |
28e80f7
to
cf64e6c
Compare
I just rebased and force-pushed to get a fresh test run. If p.s. Very pressed for time right now, so if this doesn't converge easily, happy with #15096 as a stop-gap measure... |
Alas... still 95 failed (though 3 of them are from modeling and unrelated). |
Looks like we need version check in some places?
|
Ah, right, that changed, we didn't make the new |
There are 51 failures now (3 unrelated, the rest doctest output comparison failures). I actually don't like the new look in our own doc test output... especially when you print out the WCS... it looks jarring and adds noise to the actual data I am interested in (say, what is the value of CVAL1, without also have to see it is |
ffffe25
to
a6c39c6
Compare
The problem with this PR is that all doctests will fail on older numpy. In principle, we can just not run the tests on older versions, but that makes sense only once 2.0 is actually out. I think the logical route is to go with #15096 first, so that things work again, and then do this one once 2.0 is released. |
In that case might even want to wait for numpy 2.1 for a chance for users to catch up? Or is that too long? |
@@ -121,7 +121,7 @@ class StructuredUnit: | |||
Structured units share most methods with regular units:: | |||
>>> su.physical_type | |||
((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), PhysicalType('time')) | |||
astropy.units.structured.Structure((astropy.units.structured.Structure((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), dtype=[('f0', 'O'), ('f1', 'O')]), PhysicalType('time')), dtype=[('f0', 'O'), ('f1', 'O')]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that was one case where I felt we might want to override __repr__
... I'll put it on top.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed! I think the current ((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), PhysicalType('time'))
should be the behaviour of __str__
.
For __repr__
we at least don't want to show the module structured
.
astropy.units.structured.Structure((astropy.units.structured.Structure((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), dtype=[('f0', 'O'), ('f1', 'O')]), PhysicalType('time')), dtype=[('f0', 'O'), ('f1', 'O')]) | |
astropy.units.Structure((astropy.units.Structure((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), dtype=[('f0', 'O'), ('f1', 'O')]), PhysicalType('time')), dtype=[('f0', 'O'), ('f1', 'O')]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, that is the minimal change. But coming back to this fairly substantial PR, it is probably best to do that afterwards - I raised a new issue at #15793.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally fine by me. I can review this PR in a few days, if you're ready @mhvk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This PR is basically waiting for numpy 2.0 to be released... I'm just keeping it up to date once in a while until that happens.
2dfcd6f
to
3db12fa
Compare
See fix in #16439. Combined with @larrybradley's fixes in #16431 that I already rebased on, everything should pass, which will mean this can go out of draft. Note that #16439 will bring in a |
@@ -266,6 +266,8 @@ def test_iter_coosys(self): | |||
) | |||
def test_select_missing_columns_error_message(columns, expected_missing): | |||
# see https://github.com/astropy/astropy/pull/15956 | |||
# Turn into numpy strings (otherwise match fails on numpy >= 2.0). | |||
expected_missing = [np.str_(e) for e in expected_missing] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm don't think this is the correct fix here. I'll link to my own solution when I open the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DEV NOTE: Do not merge until numpy 2.0 is actually out!
Do not merge until this is merged and available in numpy nightly wheel (when we start to see things fail in devdeps)Structure
for structure units output) - but this should not be part of this PR, so punted to Post-numpy-2.0 changes in repr/str #15793.doctest-plus
to ignorenp.float64
, etc., in comparing numerical values. 2023-Dec: seems that we are heading to a docs-on-numpy>=2.0 only stateThis is a start to adjusting our tests for the change in how scalars are formatted in NEP 51 - see numpy/numpy#22449
Note that it does not adjust tests ofrepr
and the documentation yet!Posting this in part to show that outside of
repr
this is not a big deal.In the documentation, one often will have things like
This brings up a more general question of whether we should use this opportunity of the
repr
changing to just return an array scalar (i.e., it would benp.array(5.0)
instead).Fix #15095
Fix #15792