MAINT: Reflect changes from numpy namespace refactor Part 5

[mtsokol]

Hi!
Here's a PR that reflects changes introduced in numpy/numpy#24587. (The only item that needs to be modified in matplotlib is np.recarray access)

[anntzer]

While technically correct, I would suggest just dropping the use of recarrays altogether (remove the .view(np.recarray) and replace r.attr by r['attr'] throughout). If we feel like it we could even switch to using the data kwarg (fill_between("date", pricemin, "close", alpha=0.7, data=r) etc.)

[ksunden]

As @anntzer points out, we probably don't need recarray at all.

However, if we do keep it, this change is backwards incompatible, and thus would force us to run our doc builds on np 2.0 (and potentially cause confusion for readers of the docs who are using current released numpy)

The direct impact of this change is minimal to us, as all changes are contained within examples, not library code.

There are two problems with this change that make ordering with regards to numpy a) merging and b) releasing 2.0 that may make us want to hold off on merging (or breaking up the change into two phases) possibly until after release:

• The first is making sure the examples run in our doc build environment

  • This could be worked around with conditional imports, etc

• The second is the inter-sphinx references to recarray, which are not found currently

  • I'm pretty sure we link against stable numpy docs, so this may hold off until release
  • Merging early will cause our doc builds to constantly fail, even with backwards-compatible example usage.

[jklymak]

I would not use recarray, and remove mention of it in our docs.

[mtsokol]

However, if we do keep it, this change is backwards incompatible, and thus would force us to run our doc builds on np 2.0 (and potentially cause confusion for readers of the docs who are using current released numpy)

@ksunden I think it would be beneficial to remove recarray from the codebase, but in terms of this PR I don't think it's backward incompatible.

recarray is available under np.recarray and np.rec.recarray, so switching to the second option will still work for previous numpy versions. Am I missing anything?

(The purpose of refactoring that piece of NumPy is to define only one place where this class is available)

[ksunden]

Okay, I was thinking that rec was a new namespace, but it isn't, so that prong is okay, the intersphinx not seeing it/breaking the doc build is still true though as of right now