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

As@anntzer points out, we probably don't needrecarray 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 examplesrun in our doc build environment

  • This could be worked around with conditional imports, etc

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

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

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

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 removerecarray from the codebase, but in terms of this PR I don't think it's backward incompatible.

recarray is available undernp.recarray andnp.rec.recarray, so switching to the second option will still work for previousnumpy versions. Am I missing anything?

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

Okay, I was thinking thatrec was anew 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