-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Silence sphinx warnings #4286
Silence sphinx warnings #4286
Conversation
@spencerkclark, while working on this PR I got a warning about Anyway, I don't think any of those is part of the public api? If the methods on |
Thanks for catching this; I agree they are not currently public API, so let's remove the references to them in docstrings of public functions. And it's true, I think |
Thanks a lot @keewis ! |
because that will separate combined parameter docs by duplicating the description
@keewis: this is great! |
doc/terminology.rst
Outdated
name | ||
The names of dimensions, coordinates, DataArray objects and data | ||
variables can be anything as long as they are :term:`hashable`. However, | ||
it is preferred to use :py:class:`str` typed names. | ||
|
||
scalar | ||
By definition, a scalar is not :term:`array_like`. That means that, | ||
e.g., :py:class:`int`, :py:class:`float`, and :py:class:`str` values are | ||
"scalar" while :py:class:`list` or :py:class:`tuple` are not. |
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.
these definitely need a review, I'm not quite sure these are easy to understand
most of the remaining broken links are due to other sections (mostly the |
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.
This is a great cleanup, thank you!
doc/terminology.rst
Outdated
it is preferred to use :py:class:`str` typed names. | ||
|
||
scalar | ||
By definition, a scalar is not :term:`array_like`. That means that, |
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.
Should "array like" also be defined somewhere in order for a link to work? Or does this just add some sort of formatting?
My definition of a "scalar" might be anything that isn't an array and that when converted into a NumPy array would have 0 dimensions.
NumPy defines "array like" as anything that can be converted into an array. So that definition includes scalar values.
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.
right now we're linking to numpy's definition of the term (thanks to intersphinx
), so defining it on our own might not be necessary.
I updated the definition, is it better now?
Co-authored-by: Maximilian Roos <5635139+max-sixty@users.noreply.github.com>
variables can be anything as long as they are :term:`hashable`. However, | ||
it is preferred to use :py:class:`str` typed names. | ||
|
||
scalar |
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.
LGTM.
Co-authored-by: Maximilian Roos <5635139+max-sixty@users.noreply.github.com>
Thanks @keewis. Great work! |
A Napoleonic PR! (pun intended) |
This prepares our docstrings for the improvements to
napoleon
in the upcomingsphinx
release (I'm not aware of a fixed date, thoughit's going to be released around Aug 08, so in about a week from now).napoleon
now has a stricter syntax for parameter type specs withnapoleon_use_param = True
, which allows it to link to all referenced types.We can't do much about the inherited docstrings, though, so we'd probably have to fix that upstream.
isort . && black . && mypy . && flake8
whats-new.rst
api.rst