-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Improve docstring of contour #10968
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
Improve docstring of contour #10968
Conversation
lib/matplotlib/contour.py
Outdated
The first three arguments must be: | ||
Call signature:: | ||
|
||
ContourSet(ax, levels, allsegs, [allkinds], **kwargs) |
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 would just pick some reasonable argument names (levels, allsegs and allkinds are fine, but you can also change them if you want as they were positional-only up to now) and transform this into a regular signature without custom parsing.
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 agree with the proposed change, but will leave it to a separate PR.
It's probably simple enough. I did not touch this, because there's a bit of code paths to change with _process_args
and maybe subclasses. I try to keep the docstring updates separated from really non-trivial code changes. This eases reviewing as well as backporting.
lib/matplotlib/contour.py
Outdated
If an int *n*, use *n* data intervals; i.e. draw *n+1* contour | ||
lines. The level heights are automatically chosen. | ||
|
||
If array-like, draw contour lines the specified level values. |
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.
If array-like, draw contour lines [at / on / through ?] the specified level values.
or
If array-like, contour the specified level values.
Since contour could be a verb?
lib/matplotlib/contour.py
Outdated
locator : ticker.Locator subclass, optional | ||
The locator is used to determine the contour levels if they | ||
are not given explicitly via *levels*. | ||
Defaults to `.MaxNLocator` is used. |
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.
Defaults to
.MaxNLocator
.
or
By default,
.MaxNLocator
is used.
@timhoffm If you are going to change contour/contourf documentation, you also need to change tricontour/tricontourf to be consistent. |
Call signature:: | ||
|
||
contour([X, Y,] Z, [levels], **kwargs) | ||
|
||
:func:`~matplotlib.pyplot.contour` and | ||
:func:`~matplotlib.pyplot.contourf` draw contour lines and |
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.
Why does the Axes.contour
documentation link to the pyplot.contour
documentation (which is the same)?
Same in the Notes section (line 1792 ..)
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.
Given the discussion in #10974 it might be sensible to keep the links to pyplot as the pyplot function docs have a gallery below them.
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 same docstring is used both on the Axes and pyplot interfaces, because we don't want to maintain to almost identical versions. For this we have to pay the small price that both versions link to the same functions. We have the same issue with other passthrough functions. I've left the links as they are.
lib/matplotlib/contour.py
Outdated
Optional keyword arguments: | ||
Returns | ||
------- | ||
`matplotlib.contour.QuadContourSet` |
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 should actually link to the QuadContourSet docs,
:class:`~matplotlib.contour.QuadContourSet` object.
(modulo correct syntax)
I think it would be really great if the documentation of a function could link to some (or all?) examples from the gallery that use this function. In this case those would be
I don't know at which point this would be specified, if it's in the docstring or some sphinx config file? |
I would leave the gallery links to #10974. |
Yes, except I think where #10974 has left us is with manual gallery links for most methods... |
I would agree. In the moment writing this I was under the impression that this would be an easy change.
Still, there seems no obvious solution for manually providing those links, so this should probably done indepenently of the docstring updates proposed here. In general it's great to see the documentation becoming more and more consistent. 👍 |
@ianthomas23 This is part of a larger effort #10148. tricontour/tricontourf will get their attention in due time. |
@timhoffm Understood. As contour(f) and tricontour(f) share lots of documentation, I wouldn't want them to be out of sync for long. |
@timhoffm I'd be more comfortable approving this if you just did the change in tricontour at the same time. I know you have a list, but you could do out of order just this once. But the practical reason is that if there is lots of shared text, maybe it should be interpolated across the methods... |
I don't care too much about same time. One improved docstring is better than none. 😄 I'm also a bit hesitant with too much interpolation as it's not too stable and probably wouldn't work for interpolating parameter sections until #10161 is solved. |
|
||
:: | ||
|
||
contour(X,Y,Z) |
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.
Although this example list is long, I think it makes much more sense than the 1-liner that has replaced it above, so I would be keen to keep these lines.
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.
You mean the stuff before Optional keyword arguments
? Comparing old and new, this is mostly repetitive stuff:
- Draw Z,
- Draw Z with X, Y
- Draw Z with parameter N
- Draw Z with X, Y and parameter N
- Draw Z with parameter V (which is just a more explicit control of the same property controlled by N)
- Draw Z with X, Y and parameter N (which is just a more explicit control of the same property controlled by N)
It's much easier to say and understand:
- Draw Z, optionally with X, Y and optionally with giving the levels.
I was really happy that I could boil this section down to quite a simple formula. To me it was really daunting before. I find it quite demotivating to read the doc at all, when I have to read a full screen before I have an idea, what parameters I could use.
One might add a sentence after the call signature, "where Z are the values, X, Y are the coordinates, ..". But then again, that's just a repetition of the parameter section, which is immediately following.
Can you explain the benefit you see in the long version?
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 agree that there is a long list there, but I think contour([X, Y,] Z, [levels], **kwargs)
is too terse, and confusing (can I do (X, Z)
? (Z, levels)
? e.g.). I think having a list of the allowable call signatures would be much better, and it could be boiled down to
contour(Z ...)
contour(X, Y, Z ...)
with some sort of explanation that levels
can be provided before keyword arguments.
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 by definition, the square brackets mean optional. You can use or leave out every square bracket separately. So, X, Z
does not work, but Z, levels
does.
It's maybe a question if everybody knows this convention. I'd rather use a standard python function signature instead. However that's not possible with optional positional parameters, which are often used in matplotlib. Anyway, I'm still in favor of using the standard convention for optional parameters compared to verbosely giving multiple alternatives.
I could add a sentence "X, Y must be given both, or left out both." to the paramter description, if that adds additional clarity.
I'm going to merge as an improvement. If we want to revert some of it because part have gotten too murky, thats fine, but I'm comfortable w/ the square bracket notation... |
Improve docstring of contour Conflicts: lib/matplotlib/contour.py - conflict due to de-py2-ification - docstring conflicts, kept the version from master branch
PR Summary
As part of #10148: Docstring update for
Axes.contour
/Axes.contourf
and related stuff.