API: Remove several niche objects for numpy 2.0 python API cleanup

[ev-br]

As discussed in #23999 (comment), specifically #23999 (comment), remove

• np.cast
• np.info
• np.source
• np.lookfor

An alternative is of course to formally deprecate them first :-).

[ngoldbaum]

I think np.info was supposed to stick around.

[WarrenWeckesser]

There has been recent activity related to info, e.g. #23245, #23355.

I'm ambivalent about the ultimate fate of info, but if it is to be removed, the removal must be consistent with the usual deprecation policy. Let's not get too trigger happy with removing stuff without the correct deprecation cycle; we should not fall into the normalization of deviance where we get casual about removing seemingly insignifcant things without deprecation. There should be a really compelling reason for not sticking to the standard deprecation process.

[ev-br]

OK, updated with np.info staying intact.

[rgommers]

. Let's not get too trigger happy with removing stuff without the correct deprecation cycle; we should not fall into the normalization of deviance where we get casual about removing seemingly insignifcant things without deprecation. There should be a really compelling reason for not sticking to the standard deprecation process.

There is a compelling reason, namely NumPy 2.0 which already requires new releases and wheel builds from every significant downstream package. I think this is the wrong PR to make this comment; this PR seems fine to me given
https://numpy.org/neps/nep-0052-python-api-cleanup.html#backward-compatibility. Having it deprecated in 2.0 and then removed in 2.2 is kind of pointless work for these APIs, and has a negative impact on one of the key goals for 2.0.

[rgommers]

I had a look at np.info and the linked issues - it seems like it is useful to some users, but the docstring for it is completely wrong - it is not at all equivalent to help/?.

[seberg]

I would like to always think of the two things:

• who is affected: in this case at least probably very few, and most of the functions are docs, so no-one in production
• how are they affected: I think in this case the replacement is rather obvious.

I will grant that np.info has probably uses and users at least for teaching, so happy to keep it.

[seberg]

@ev-br can you add brief release notes? Maybe with a sentence saying to replace np.cast with the call to .astype() or np.asarray(..., dtype=)? (I guess for source, ?? or inspect may also be something we could point to)

EDIT: Forgot to metion, there is a python_removal category (iirc, there should be one fragment/file already)

[seberg]

But, if anyone disagrees, I don't mind making it a deprecation, I just think the step adds little beyond allowing downstream to work without updates, and large chunks of downstream won't have that (and this won't be the reason why).

[ev-br]

can you add brief release notes

Sure, done.

[seberg]

Test failures are unfortunately real, there seem to be remains of these in the typing tests.

[ev-br]

CI is 🟢

[seberg]

Grrrrrrr, I did a github code search found a decent amount of np.cast[ usage. Considering that it's ugly but trivial code, probably it's better to only deprecate it :(.

I can follow up with that and finish that, though.

[rgommers]

Grrrrrrr, I did a github code search found a decent amount of np.cast[ usage. Considering that it's ugly but trivial code, probably it's better to only deprecate it :(.

If it's trivial to update, I think we should remove it. And otherwise we have to ensure it's not in the reference guide anymore - in this particular case that's already true though, so no extra work (but also an extra reason to remove, it was never even meant as public API).

[seberg]

Ok, let's roll with it. I will note that if anyone complains about np.cast with some conviction, I will vote to revert it. I don't really think its worth (+pushing through/spending many "annoy users" chips on).

The replacement suggesting might not create a copy when there previously was, but I don't think that should be a problem, but rather an improvement in most cases.

[jakevdp]

One note: removing cast breaks scipy, which imports it here: https://github.com/scipy/scipy/blob/v1.11.1/scipy/linalg/_decomp.py#L22

Discovered because JAX's upstream nightly CI failed: google/jax#16864

Should there be some kind of deprecation cycle here? Left as is, the next numpy release will cause all existing scipy releases to error on import.

[ev-br]

scipy usage will get fixed later today, thanks for finding it!
I believe released scipy versions have an upper pin for numpy < 2.0.

[seberg]

I am not worried about SciPy since it must adapt to 2.0 anyway as a C-API user. But it is a data-point towards it being used enough to go through a deprecation to help smooth transition for small less maintained Python libs that may also use it.

[ev-br]

scipy PR: scipy/scipy#18973

[rgommers]

I will write up a short proposal here and send it to the mailing list. Basically everything we want to remove is used somewhere, and what I would like to avoid is that we avoid any pain in 2.0 and as a result make 2.2 the major breaking release. That'd be worse. There may be things that indeed do deserve only a deprecation and removal in 2.2 or even later, but we cannot do that for every niche API. EDIT: done in this message