Should I add deprecation message or are these too niche to mention that?

Searching on github, there seems to be a lot of usage ofnewbyteorder to get a byteswapped version of an array. Likehere in pandas.

ptp also seems to have a decent amount of downstream usage, e.g.here in matplotlib.

usage ofsetitem is harder to evaluate because the name isn't really unique to numpy in python code, but usages in popular downstream libraries don't immediately pop out in my search.

From that, I think we definitely at least need anAttributeError that tells people what the migration is when people access the removed attributes. I'm also a tiny bit nervous that the migration we need to suggest fornewbyteorder might get complicated, judging by the documentation update. The most common usage seems to be doingarray.byteswap().newbyteorder() to get a byteswapped copy. Is there a copy-pasteable idiom we can suggest instead that doesn't depend on details on the current dtype?

I'm also a tiny bit nervous that the migration we need to suggest fornewbyteorder might get complicated, judging by the documentation update. The most common usage seems to be doingarray.byteswap().newbyteorder() to get a byteswapped copy. Is there a copy-pasteable idiom we can suggest instead that doesn't depend on details on the current dtype?

As a replacement I'm using:

arr.view(arr.dtype.newbytorder(new_order))

asnp.ndarray.newbyteorder points out that they are equivalent.

Let me know if you need a hand setting up theAttributeError in C (or just a deprecation if we decide an outright error is too disruptive).

Let me know if you need a hand setting up theAttributeError in C (or just a deprecation if we decide an outright error is too disruptive).

@ngoldbaum Right, I forgot to add them. I pushed new changes - now inndarray and scalar types, when accessing each of these functions, a customAttributeError is raised.

It looks like matplotlib is ready. Are there any other downstream libraries we need to wait on PRs for?

I checked other libraries and opened four PRs that reflect changes introduced there:

• scipy:MAINT: Cleanup expired ndarray methods scipy/scipy#19253
• joblib:MAINT: Cleanup expired ndarray methods joblib/joblib#1506
• pandas:MAINT: Cleanup expired ndarray methods pandas-dev/pandas#55180
• scikit-learn:MAINT: Cleanup expired ndarray methods scikit-learn/scikit-learn#27401

Then we're good to go.

Bothptp anditemset I have used quite a lot. The removal ofptp is ok, it is a bit slower, but not too much:

import numpy as npimport numpy.core.multiarray as mux=np.random.rand(20,)%timeit np.ptp(x)%timeit x.ptp()%timeit mu.maximum.reduce(x) - mu.minimum.reduce(x) # more verbose, but a fast alternative

results in:

5.2 µs ± 16.2 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)4.36 µs ± 181 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)2.69 µs ± 14.5 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

Theitemset is a bit strange:

import numpy as npx = np.random.rand(10,)r = np.random.rand(3, 3)%timeit x.itemset(2, 3)%timeit x[2] = 3%timeit r.itemset(2, 3)%timeit r[2] = 3%timeit r.itemset(0, 1, 3)%timeit r[0, 1] = 3

results in

120 ns ± 3.04 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)98.9 ns ± 0.14 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)168 ns ± 18.1 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)440 ns ± 15.2 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)143 ns ± 4.72 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)121 ns ± 5.59 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

So the normal indexing is even faster than a directitemset, even though the documentation for itemset claims "Compared to indexing syntax,itemset provides some speed increase ..." (in older versions of numpy/python this was true). The only exception is for indexing a 2D array with a single index. But that case might be rare.

@mtsokol The title of the PR containssetitem, maybe change that intoitemset?

@eendebakpt Ah yes, I did a typo - fixed.

All the downstream PRs are merged so let's pull this one in. Thanks@mtsokol. As always, if you're reading this because of CI breakage and you think we made a mistake in this PR and the migrations we've offered aren't sufficient, please open an issue.

Were there deprecation warnings added to NumPy 1 for these removals somewhere?

Were there deprecation warnings added to NumPy 1 for these removals somewhere?

Given that it's a major version bump we decided to do a few API cleanups without any deprecation, including these. If that proves to be too disruptive, we're open to re-adding with deprecation warnings.

We just ran into it when testing between NumPy 1 & 2

I don't think we need to readd them as there is a path to using the functions instead of the methods

Though it might be worth adding a deprecation warning in the next NumPy 1 release just so users know this is coming

cc@grlee77 (who ran into this; in case you have more thoughts here)