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

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

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

usage of setitem 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 an AttributeError 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 for newbyteorder might get complicated, judging by the documentation update. The most common usage seems to be doing array.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 for newbyteorder might get complicated, judging by the documentation update. The most common usage seems to be doing array.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))

as np.ndarray.newbyteorder points out that they are equivalent.

Let me know if you need a hand setting up the AttributeError 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 the AttributeError 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 in ndarray and scalar types, when accessing each of these functions, a custom AttributeError 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.

Both ptp and itemset I have used quite a lot. The removal of ptp is ok, it is a bit slower, but not too much:

import numpy as np
import numpy.core.multiarray as mu
x=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)

The itemset is a bit strange:

import numpy as np
x = 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 direct itemset, 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 contains setitem, maybe change that into itemset?

@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)