Autogenerate (via boilerplate) more of pyplot. #10934
Conversation
lib/matplotlib/axes/_base.py
Outdated
| """ | ||
| Display minor ticks on the axes. | ||
|
|
||
| Displaying minor ticks reduces performance; turn them off using |
There was a problem hiding this comment.
Is this really significant? If so, this is an implementation detail.
I would put it in a Note, and formulate a bit more defensive: "Displaying minor ticks may reduce performance. You may turn them off using ...`.
lib/matplotlib/axes/_base.py
Outdated
| @@ -1601,7 +1601,8 @@ def apply_aspect(self, position=None): | |||
| self.set_xbound((x0, x1)) | |||
|
|
|||
| def axis(self, *v, **kwargs): | |||
| """Set axis properties. | |||
| """ | |||
| Convenience method to get or set some axis properties. | |||
|
|
|||
| Valid signatures:: | |||
There was a problem hiding this comment.
I think we now use the term "Call signatures".
lib/matplotlib/axes/_base.py
Outdated
|
|
||
| This image will be the target of colormap functions like | ||
| `~matplotlib.pyplot.viridis`, and other functions such as | ||
| `~matplotlib.pyplot.hot` or `~matplotlib.pyplot.clim`. The current |
There was a problem hiding this comment.
remove "hot". It's a cmap like viridis.
|
comments handled |
lib/matplotlib/axes/_base.py
Outdated
| changing dimensions of the plot box. | ||
| 'tight' Set limits such that all data is shown; if this is already | ||
| the case, move data to the center of the figure without | ||
| modifying ``xmax-xmin`` or ``ymax-ymin``. |
There was a problem hiding this comment.
I don't understand; what is an example of the second case, where the limits are changed without changing their differences?
There was a problem hiding this comment.
Indeed the description seems to be incorrect.
>>> fig, ax = plt.subplots()
>>> ax.plot([1,3,2])
>>> ax.get_xlim()
(-0.1, 2.1)
>>> ax.set_xlim(right=4.1)
(-0.1, 4.1)
>>> ax.axis('tight')
(-0.1, 2.1, 0.9, 3.1)
>>> ax.get_xlim()
(-0.1, 2.1)
From the description I would have anticipated (-1.1, 3.1). Anyway, the implemented behavior seems more reasonable. I don't see why 'tight' should preserve xmax-xmin. So the docstring should be changed.
There was a problem hiding this comment.
Well, I just copied the pyplot docstring :-) Removed the offending sentence, although now it's unclear how this is different from "auto".
As a side note (but not changed by this PR), the docstring of autoscale() states that
tight: bool or None, optional
If True, set view limits to data limits;
if False, let the locator and margins expand the view limits;
if None, use tight scaling if the only artist is an image,
otherwise treat *tight* as False.
The *tight* setting is retained for future autoscaling
until it is explicitly changed.
implying that autoscale=True ignores margins. But either that's not true, or axis('tight') has a different meaning per @timhoffm's example. Note also the docstring of autoscale_view:
If *tight* is *False*, the axis major locator will be used
to expand the view limits if rcParams['axes.autolimit_mode']
is 'round_numbers'. Note that any margins that are in effect
will be applied first, regardless of whether *tight* is
*True* or *False*. Specifying *tight* as *True* or *False*
saves the setting as a private attribute of the Axes; specifying
it as *None* (the default) applies the previously saved value.
so is tight=False basically redundant with the axes.autolimit_mode rc? All that's very confusing...
|
rebased |
PR Summary
... namely
axis,minorticks_{on,off},title,{x,y}lim,{x,y}scale, andsci.This helps maintaining the signatures (cf.
title) and docstring (cf.axis) in sync.PR Checklist