Skip to content

Conversation

@eendebakpt
Copy link
Contributor

@eendebakpt eendebakpt commented Aug 28, 2025

Description

Replaces direct setting of the shape and dtype parameters of numpy arrays.

In this PR we handle only part of the cases. In followup PRs the remaining cases can be handled.

Fixes (partly) #18561

@github-actions
Copy link
Contributor

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?
  • 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.

@eendebakpt eendebakpt changed the title Use reshape instead of setting shape directly on numpy arrays Replace deprecated setting of shape and dtype on numpy arrays Aug 28, 2025
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this change is invisible to users, we do not need a change log. Please delete this file and squash it out in your commit. Thanks!

@pllim
Copy link
Member

pllim commented Aug 28, 2025

Thanks!

I am leaning against not backporting since the upstream PR is still open and maybe by the time the warning hits us, v7.1.x would be retired.

Copy link
Contributor

@mhvk mhvk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eendebakpt - thanks so much for taking this on! I think most changes here are straightforward and none are in places where a few us is going to matter. So, I'm happy to just approve for the various subpackages.

But I'd like to do uncertainty separately, since speed there is more important, and also I think that the two changes you have here are not the only ones - there is a specific dtype setter that I at least would want to think a bit more about. It may be that it is reasonable here to use the private methods that still allow setting.

Anyway, bottom line would be to try to only do sub-packages here in which this PR makes them fully compatible with the future numpy 2.4!

With that request to remove uncertainty for now, I guess you might as well address my minute comments, of using .reshape() more directly (see in-line comments).

def test_groups_hdu_data(self):
imdata = np.arange(100.0)
imdata.shape = (10, 1, 1, 2, 5)
imdata = imdata.reshape((10, 1, 1, 2, 5))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: I'd add the .reshape to the definition, like you do below.

if shape is not None:
a.shape = shape
b.shape = shape
a = a.reshape(shape)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This routine can be fairly easily rewritten to not do the ravel, reshape at all. I can push a commit to your branch, though perhaps it is better I do it in follow-up, so we can just get this in first, since what you have here is the obvious solution of just replacing setting .shape with a .reshape().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I prefer a followup pR.

self.n1 = rsn.standard_normal(self.x1.size) * 0.1
self.n2 = rsn.standard_normal(self.x2.size)
self.n2.shape = self.x2.shape
self.n2 = self.n2.reshape(self.x2.shape)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe do the reshape on the definition.

structured = np.asarray(DummyArray(interface, base=samples))
# Set our new structured dtype.
structured.dtype = new_dtype
structured = structured.view(new_dtype)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably not quite it for uncertainty, correct? If so, I'd prefer to do uncertainty separately -- maybe for that one it is worth using the private methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reverted the changes for now just to be sure.

@eendebakpt
Copy link
Contributor Author

Anyway, bottom line would be to try to only do sub-packages here in which this PR makes them fully compatible with the future numpy 2.4!

So far I picked the low-hanging fruit, but indeed it might be good to organize per sub-package.

In the io.fits subpackage there are some more changes needed, in particular for sections where a byteswap is done such as

https://github.com/astropy/astropy/blob/main/astropy/io/fits/hdu/groups.py#L536-L559

@mhvk
Copy link
Contributor

mhvk commented Aug 28, 2025

I think it would help review indeed to split out sub-packages that are more tricky, ensuring that with whatever is merged, a sub-package is ready to face the immutable shape/dtype/stride world...

Copy link
Contributor

@mhvk mhvk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, even if this doesn't quite complete fits, I think it is a good start, and all the changes are good even if numpy never were to deprecate settings .shape and .dtype. Thanks, @eendebakpt!

@mhvk mhvk merged commit 1ba18e8 into astropy:main Aug 29, 2025
30 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants