-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Replace ACCEPTS by standard numpydoc params table. #11397
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
Conversation
ACCEPTS: float | ||
Parameters | ||
---------- | ||
val : float |
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.
Would it make sense to use type annotations for these very simple cases? The type could be inferred from the type annotation. We could leave out the Parameters section which is quite verbose just for specifying a simple type, both in source code and in the generated html.
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.
That's a discussion for another time...
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.
Well, just saying. It's just one line in the ArtistInspector
(actually none, because you can delete another line for that). And it saves a lot of boilerplate docstring code.
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.
I'd be more comfortable if we can draw a policy as to where to draw the line between strict annotations and "vague" type docstrings. Especially for Matplotlib, there are many cases where the exact type is complicated or it's actually the value (rather than just the type) that's important.
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.
The policy for the docstring is: Describe the expected input parameters in a way, that is easy to read and understand by a human user. The numpydoc howto gives some helpful guidelines that should be followed if possibe.
I currently would only use type annotations for simple cases as the one above. Anyway, should we have both later on, the docstring type should be given preference. It's really only that you don't need verbose boilerplate code like
Parameters
------------
theparam : float
But I don't hold you up on this.
(In the cases where this is "easy".)
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 really cleans things up a lot! Thanks for the huge effort. Some questions, but some of them could be future PRs (particularly the issues w/ 'color')...
Parameters | ||
---------- | ||
value : {"linear", "log", "symlog", "logit"} | ||
value : {"linear", "log", "symlog", "logit", ...} |
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.
I know there is an ellipsis above, but what does it mean?
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.
It's all the scales registered in the _scale_mapping dict.
Parameters | ||
---------- | ||
anchor : str or 2-tuple of floats | ||
anchor : 2-tuple of floats or {'C', 'SW', 'S', 'SE', ...} |
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.
Is the ellipsis because its obvious what the other arguments are? Maybe not so obvious for non-english readers?
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.
It’s explained in the following docstring.
Parameters | ||
---------- | ||
value : {"linear", "log", "symlog", "logit"} | ||
value : {"linear", "log", "symlog", "logit", ...} |
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.
as above..
ACCEPTS: A :class:`~matplotlib.ticker.Formatter` instance | ||
Parameters | ||
---------- | ||
formatter : ~matplotlib.ticker.Formatter |
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.
Sorry for my ignorance and laziness to not check the render - does this resolve to a link?
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.
Apparently it doesn't (https://3226-7439715-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/api/_as_gen/matplotlib.axis.Axis.set_major_formatter.html#matplotlib-axis-axis-set-major-formatter), but some minimal testing (on another project) shows that napoleon (instead of numpydoc) does resolve it. Which, I guess, is a good reason to revive #5743 (unless I missed some way to achieve this with numpydoc).
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.
I'll ask one of the numpydoc devs. In the meantime, let's move forward on that without this sorted out. This is a great improvement on what we had before.
|
||
Parameters | ||
---------- | ||
c : matplotlib color arg or sequence of rgba tuples |
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.
Is there a way to link the color arg page here?
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.
Probably, but I'd rather you just open an issue and we try to resolve that as a separate thing.
Parameters | ||
---------- | ||
every: None | int | length-2 tuple of int | slice | list/array of int \ | ||
| float | length-2 tuple of float | ||
every: None or int or (int, int) or slice or List[int] or float or \ |
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.
Do we need the 'or' after everything in this list for some reason? one of: None, int, (int, int), slice, List[ind], float, or (float, float)
would be easier to read. Or separate by semicolons?
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.
See http://www.sphinx-doc.org/en/master/usage/restructuredtext/domains.html#info-field-lists ("Multiple types in a type field will be linked automatically if separated by the word “or”").
ACCEPTS: mpl color spec, None, 'none', or 'auto' | ||
Parameters | ||
---------- | ||
color : color or None or 'auto' |
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.
We have a :rc: alias, right? Do we need a :color: alias so that all instances of color can point to the definition?
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.
Probably a good separate issue, per above.
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 big enough that maybe someone else should approve as well. @timhoffm are you OK w/ this now?
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.
Basically ok, even though I'm still not a fan of adding verbose boilerplate Parameter sections just to define a simple type for a parameter.
The type definitions should use full names and not be abbreviated by ~
.
I don't think any of the comments are blockers, so I'm going to go ahead and merge it. Thanks everyone! |
(In the cases where this is "easy".)
Followup to #11300.
PR Summary
PR Checklist