Have you looked at all at how noisy this is downstream? It's a little hard to search for but I suspect this pattern is used quite a bit. It would probably help us to understand what downstream usage looks like to try running some downstream test suites with a patched numpy to see how noisy it is.

SciPy is probably a good choice, maybe astropy too because they implement an ndarray subclass. I'd skip pandas because its test suite takes a very long time to run outside of github actions.

Astropy indeed uses setting the dtype and shape. I created a ticket and a PR astropy/astropy#18562. Lets see how this is picked up before merging this PR.

In astropy the only deprecated cases left are cases where we expect to use the new ndarray._set_dtype from this PR. So I think this PR is ready.

Alternatively, we split this PR to first merge the _set_dtype and merge the rest a bit later (when downstream has had some time to adapt).

Since there is a PR ready to go, I don't think it is worth the effort to split this.

Grepping around in pandas, it seems the only uses are in self.dtype = in non-ndarray class __init__ methods. Maybe I am optimistic.

I think this needs a mailing list ping to be mergeable.

Reference to thread on mailing list archive: https://mail.python.org/archives/list/[email protected]/thread/FLSZFJ2TDLXHMFAUIYNM43VZQ7T73LZR/

Thanks for your patience here @eendebakpt. I think we've done our due diligence.

@seberg, can I nominate you to hit the merge button if you agree?

this needs a rebase

Sorry for missing this. Let's put it in, thanks everyone.

While not the best, if you are hit by this and views don't work, you can use ._set_dtype(), but please do leave a comment/issue with the use-case, so we know that it is used and also understand the why a bit.

if you are hit by this and views don't work, you can use ._set_dtype(), but please do leave a comment/issue with the use-case,

hi there. I just used it in astropy to adapt a class that inherits from numpy.ndarray, assuming that's okay
astropy/astropy#19540

I just used it in astropy to adapt a class that inherits from numpy.ndarray, assuming that's okay

I think the question here is whether there is a reason that you cannot follow the NumPy deprecation here for the Column class?

EDIT: I.e. can't you almost as easily fix the yt code to avoid it instead.

Oh I do plan to follow the deprecation, but I can't introduce a deprecation in a patch release, so I'll only do it for astropy 8.0.0, while the patch I linked is meant to be backported as is to 7.2.x

EDIT: I.e. can't you almost as easily fix the yt code to avoid it instead.

meaning ? feel free to join me in the convo downstream if you have guidance. Thanks !

I am mostly wondering if you can't just "blame NumPy", i.e. this deprecation (from an astropy perspective) is related to the users NumPy version and not an astropy (minor) version "introducing it" (even if you react to it)?
The warning (even if astropy makes it more specific) could say it was introduced by NumPy 2.5? (Maybe this is weird?!)

From a yt perspective, I guess the question is how important these path that magically convert integer arrays to float arrays of the same size are for users.
Admittedly, that seems a bit tricky to judge (and if there is an easy workaround for the user, the NumPy warning wouldn't make that very clear).

I suppose, my first feeling is that yt using _set_dtype (possibly with a more specific DeprecationWarning that again might blame NumPy) might be the better spot for this fix. But I am happy to trust you either way. Thanks for the info! The yt use-case probably does need _set_dtype(), if -- hopefully -- just for transitioning.

@eendebakpt in case you want to follow up quickly, I missed that the warning says "2.4" rather than "2.5".

The warning (even if astropy makes it more specific) could say it was introduced by NumPy 2.5? (Maybe this is weird?!)

We've seen all kinds of complaints when upgrading numpy "breaks" astropy by introducing warnings (because many projects test with warnings treated as errors), so I'm reallyjust taking the path of least resistance, but I don't disagree with you, personally.

in case you want to follow up quickly, I missed that the warning says "2.4" rather than "2.5".

already fixed at #31186 ;-)

@eendebakpt there is a single instance that I think you missed, and it's showing up as a warning in wheel build jobs now:

If that was by accident, would you be able to fix that up?