-
-
Notifications
You must be signed in to change notification settings - Fork 7.8k
DOC: Add links to explicit vs implicit API everywhere "OO" is used #22613
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
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.
👍 Overall looks good to me, mostly just suggestions for tightening up "single space after a period" and "trade-off" with a dash.
doc/api/index.rst
Outdated
@@ -114,10 +114,33 @@ Alphabetical list of modules: | |||
Usage patterns | |||
-------------- | |||
|
|||
Below we describe several common approaches to plotting with Matplotlib. | |||
Below we describe several common approaches to plotting with Matplotlib. See |
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.
Below we describe several common approaches to plotting with Matplotlib. See | |
Below we describe several common approaches to plotting with Matplotlib. See |
tutorials/introductory/lifecycle.py
Outdated
The first is an explicit object-oriented (OO) interface. In this case, we | ||
utilize an instance of :class:`axes.Axes` in order to render visualizations on | ||
an instance of :class:`figure.Figure`. The second is based on MATLAB and uses |
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 seems a bit jargony with the use of "render" here. My assumption for the audience is someone pretty new to MPL and interested in "plotting", "visualizing", and "showing" not necessarily rendering. So, perhaps one of those words instead here?
# in a figure, plots some lines in a plotting area, decorates the plot | ||
# with labels, etc. | ||
# :mod:`matplotlib.pyplot` is a collection of functions that make matplotlib | ||
# work like MATLAB. Each ``pyplot`` function makes some change to a figure: |
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.
# work like MATLAB. Each ``pyplot`` function makes some change to a figure: | |
# work like MATLAB. Each ``pyplot`` function makes some change to a figure: |
# from an ``Axes`` object. We recommend browsing the tutorials and | ||
# examples to see how this works. | ||
# the implicit pyplot API is generally terser but less-flexible than the | ||
# explicit API. Most of the function calls you see here can also be called |
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.
# explicit API. Most of the function calls you see here can also be called | |
# explicit API. Most of the function calls you see here can also be called |
Co-authored-by: Greg Lucas <greg.m.lucas@gmail.com>
Co-authored-by: Greg Lucas <greg.m.lucas@gmail.com>
Looks like it was rendering as definition list due to the extra indenting.
ff17886
to
c1df30e
Compare
Co-authored-by: Oscar Gustafsson <oscar.gustafsson@gmail.com>
I am not sure how I feel about the 1 space vs 2 space. I think we have a mix in the documentation and I prefer 2 spaces and tend to write that way, but if people feel very strongly we should document it. |
I'm pretty firmly in the "one space" camp, but won't block over it at all. I mostly just prefer consistency over anything else. I think all style-guides now suggest one space. |
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.
Interestingly enough, it looks like the final page's html actually only has one space after a period, so I guess the extra whitespace is somehow gobbled up somewhere along the path.
I just noticed that the list of Modules on the API reference page is quite long and pushes the explicit/implicit discussion to the bottom. So, maybe swap the order and put the long list of modules to the bottom of that page instead to bring the interface discussion up higher?
I looked at replacing all "" in the repo and it touches over 500 files..... |
PR Summary
Closes #18249
I search for every use of "object-oriented" in the code base and make sure they all had some reference to the https://matplotlib.org/devdocs/users/explain/api_interfaces.html
PR Checklist
Tests and Styling
pytest
passes).flake8-docstrings
and runflake8 --docstring-convention=all
).Documentation
doc/users/next_whats_new/
(follow instructions in README.rst there).doc/api/next_api_changes/
(follow instructions in README.rst there).