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.
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 |
shoyer
left a comment
There was a problem hiding this comment.
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.
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.
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 |
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
napoleonin the upcomingsphinxrelease (I'm not aware of a fixed date, thoughit's going to be released around Aug 08, so in about a week from now).napoleonnow 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 . && flake8whats-new.rstapi.rst