-
-
Notifications
You must be signed in to change notification settings - Fork 719
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pin numpydoc to avoid doubly-escaped *
#3530
Conversation
@jrbourbeau this may be a better solution than the one I pushed up to dask/dask, but we can also pin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gforsyth! I'm new to napoleon. It looks like the styling of API docs is slight different (not an issue IMO). For example, with numpydoc:
with napoleon:
It also looks like there may be support for using type annotations in generated API docs, which would be great. Do you know of other difference between numpydoc and napoleon?
Also cc @jsignell who has been working on our docs recently and @jcrist who (may?) have starting using napoleon in other projects
Just that they're roughly equivalent. I also don't have a preference on styling, although it should probably match across all dask projects -- if folks are ok with the general styling change I can swap this out in the other repos, too. |
I've used both in the past. In general both seem to work fine, but they style things differently. Agree with Gil that it'd be good to standardize this across projects, no strong preferences either way. |
This change seems reasonable to me. No strong feelings on the style change. |
Sorry for the delayed reply here. I think I'd rather stick with numpydoc for the time being. Not all of our docstrings follow the official numpydoc style for their Napoleon: Numpydoc: We could also reformat our docstrings, which could be done in a future PR |
Good with me, I don't have strong opinions on this either way. I'll change this PR to pin |
*
Hey @jrbourbeau -- updated this to pin Small changes to avoid a sphinx timeout looking for an intersphinx inventory, and a fixed a misformatted code-block |
Similar to dask/dask#5961, recent changes to `numpydoc` lead to function signatures displayed using `autosummary` to have doubly-escaped `*`s. This pins `numpydoc` to version 0.8.0 to avoid the regression until a patch is merged upstream. Also small changes to avoid a sphinx timeout looking for an intersphinx inventory, and a fixed a misformatted code-block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gforsyth!
@@ -382,7 +383,7 @@ | |||
# and the Numpy documentation. | |||
intersphinx_mapping = { | |||
"python": ("https://docs.python.org/3", None), | |||
"numpy": ("http://docs.scipy.org/doc/numpy", None), | |||
"numpy": ("https://docs.scipy.org/doc/numpy", None), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 😎
Good catch @jrbourbeau! Do we need a follow on issue to coerce all the docstrings to numpydoc style? |
I opened up #3578 for updating the docstring style |
Similar to dask/dask#5961, recent changes to
numpydoc
lead to functionsignatures displayed using
autosummary
to have doubly-escaped*
s.This commit swaps out
numpydoc
in favor ofnapoleon
-- there are acouple of benefits:
I've added a make target to automatically generate API docs using
sphinx-apidoc
but this isn't required forautosummary
compatibility.It can always be added as a requirement of the
html
target at a latertime.