Changes in python and C documentation are only reflected in the sphinx build after rebuilding numpy: pip install .; cd docs; make html.

You can see the ci result here if you open the "build devdocs w/ref warnings" fold. Comparing this build to a random PR's run the number of warnings dropped from 190 to 184. 👍

There is still a mention of

:mod:`emath`

in the RST documentation, could you take a look at that too? I think it should become

``emath``

with no link. What do you think?

Hi matt, thanks for the feedback.

I had a look at doc/source/reference/routines.emath.rst and I think changing to :mod:numpy.emath to just emath with no link would be good.

It seems that sphinx can't find the np.emath module but I'm not sure why. The documentation page for emath (https://numpy.org/doc/stable/reference/routines.emath.html) says that emath should be available after numpy is imported. Do you know if sphinx just searches for emath in the numpy package after importing it?

It seems that sphinx can't find the np.emath module

I am not sure which occurence this is referring to, but if you are using np.emath, I am pretty sure you need to change that to numpy.emath

Okay, thanks. I added the small additional change to doc/source/reference/routines.emath.rst replacing :mod:numpy.emath to numpy.emath as a code block. Is there anything else I should change as part of this PR?

Doesn't numpy.emath works as a link? It seems strange to refer to this as a preferred alias but then to not be able to use it.

It seems strange to refer to this as a preferred alias but then to not be able to use it.

Agreed - I'm -1 on changing all the links from emath.* to lib.scimath.* even though it fixes the broken links, since the docs state that emath is the preferred module name. I think the right way to fix this would be to update the module name/alias to reflect the "desired" access name. Not quite sure how difficult that will be but it's likely to be more involved than a docs-only change.

I agree it's a bit weird.

I think I figured out a better way to fix it that should keep the emath type links. We can add two module documentation files doc/source/reference/routines.lib.scimath.rst and doc/source/reference/routines.emath.rst so each one generates the same documentation but with an appropriate module reference. The documentation in routines.lib.scimath.rst is under the module lib.scimath while the documentation in routines.emath.rst is under the module emath. What do you think?

Do you have any ideas how to fix the ci/circleci errors? It says there's an error in the Sphinx parallel build but I can't think of why that would be.

Do you have any ideas how to fix the ci/circleci errors? It says there's an error in the Sphinx parallel build but I can't think of why that would be.

I think this was a problem with one of the dependencies which has been fixed, try rebasing on (or merging with) main.

I think I've fixed the issue. I ended up changing the routines.emath.rst file to reference the numpy.emath module whereas previously routines.emath.rst referenced the numpy.lib.scimath module. This fixes the missing links to function belonging to numpy.emath and allows using the preferred alias.

Nice. If this is ready please remove the draft status

@mattip It's now ready for review.

Thanks @jon-deng

No problem and thanks for merging.

Hi-five on merging your first pull request to NumPy, @jon-deng! We hope you stick around! Your choices aren’t limited to programming – you can review pull requests, help us stay on top of new and old issues, develop educational material, work on our website, add or improve graphic design, create marketing materials, translate website content, write grant proposals, and help with other fundraising initiatives. For more info, check out: https://numpy.org/contribute
Also, consider joining our mailing list. This is a great way to connect with other cool people in our community and be part of important conversations that affect the development of NumPy: https://mail.python.org/mailman/listinfo/numpy-discussion