[Fix] Fix numpy.core.einsumfunc deprecation

[fjosw]

After the 1.7.0 release I noticed the following deprecation warning:

autograd/numpy/numpy_wrapper.py:7: DeprecationWarning: numpy.core.einsumfunc is deprecated and has been renamed to numpy._core.einsumfunc. The numpy._core namespace contains private NumPy internals and its use is discouraged, as NumPy internals can change without warning in any release. In practice, most real-world usage of numpy.core is to access functionality in the public NumPy API. If that is the case, use the public NumPy API. If not, you are using NumPy internals. If you would still like to access an internal attribute, use numpy._core.einsumfunc._parse_einsum_input.

This PR simply replaces the import from numpy.core.einsumfunc by numpy._core.einsumfunc which should fix the warning but adds the risk that _parse_einsum_input might break in a furture numpy release without prior warning.

[fjosw]

And this might actually break autograd in combination with numpy<2 so we would either need to bump the dependency version or change this to a version dependent import. Any preference @agriyakhetarpal ?

[agriyakhetarpal]

Thanks for noting that, @fjosw! Yes, it might be too early to remove backwards compatibility with NumPy <2, so a version-dependent import would be better here. I think the best time to enforce NumPy>2 support would be when SciPy itself can't build against NumPy<2 – newer releases for it can do so right now just fine, so that day would be the one to suggest that NumPy v1 can be considered legacy code (or when the majority of Cython extensions will build against NumPy 2, which would take longer).

Also, we do have some bits of legacy code here and there, plus imports of private modules like this – and it will become difficult to fix them in the coming time, so we need a plan. I would propose running tests with the NumPy and SciPy nightlies so that we can catch such deprecations/removals early, which I can volunteer to implement once I migrate the tox testing configuration to nox :)

Also, I think it would make sense to run tests against a suitable NumPy v1.X to determine and subsequently maintain a lower bound for NumPy versions going forward, do you have any thoughts?

[agriyakhetarpal]

See also:

1. Notes from the NumPy docs we should have in mind:
   • https://numpy.org/devdocs/dev/depending_on_numpy.html#testing-against-the-numpy-main-branch-or-pre-releases
   • https://numpy.org/devdocs/dev/depending_on_numpy.html#runtime-dependency-version-ranges
2. Package indices (or an index, rather, we have just one) to grab nightly wheels from for NumPy and SciPy: https://anaconda.org/scientific-python-nightly-wheels/repo

[fjosw]

I agree with you, that we should probably keep NumPy 1 compatibilty for now (even though people could just use an older version for now, at least until we do not add additional features).

And thanks for offering to include tests with the Nightly builds! And I also agree, that we should run at least one ci workflow with NumPy 1 as long as we want to support it.

[agriyakhetarpal]

Thank you for your thoughts! I'll work on those soon, then. Please feel free to merge if this is ready, or fix any other similar deprecation warnings if there are more.