Skip to content

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

Merged
merged 1 commit into from
Jun 22, 2018

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Jun 7, 2018

(In the cases where this is "easy".)

Followup to #11300.

PR Summary

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

ACCEPTS: float
Parameters
----------
val : float
Copy link
Member

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.

Copy link
Contributor Author

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...

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

@timhoffm timhoffm Jun 7, 2018

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".)
Copy link
Member

@jklymak jklymak left a 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", ...}
Copy link
Member

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?

Copy link
Contributor Author

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', ...}
Copy link
Member

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?

Copy link
Member

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", ...}
Copy link
Member

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
Copy link
Member

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?

Copy link
Contributor Author

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).

Copy link
Member

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
Copy link
Member

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?

Copy link
Contributor Author

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 \
Copy link
Member

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?

Copy link
Contributor Author

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'
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

@jklymak jklymak left a 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?

@jklymak jklymak added this to the v3.0 milestone Jun 19, 2018
Copy link
Member

@timhoffm timhoffm left a 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 ~.

@NelleV
Copy link
Member

NelleV commented Jun 22, 2018

I don't think any of the comments are blockers, so I'm going to go ahead and merge it. Thanks everyone!

@NelleV NelleV merged commit e09dece into matplotlib:master Jun 22, 2018
@anntzer anntzer deleted the noACCEPTS branch July 9, 2018 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants