-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Clean up and enhance plot method docstrings #5285
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
confusing to have it showing in there
max-sixty
left a comment
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.
xarray/plot/dataset_plot.py
Outdated
| Variable by which to color scattered points or arrows. | ||
| hue_style: str, optional | ||
| Can be either 'discrete' (legend) or 'continuous' (color bar). | ||
| Can be either ``'discrete'`` (legend) or ``'continuous'`` (colorbar). |
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.
@keewis would you mind opining on the best format for literals in docstrings?
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, str literals? We're currently not consistent in our code base so I think we're free to choose. If we choose to use double-backticked quoted strings (which looks better in the rendered version and slightly decreases the readability in pydoc / source code) I would vote for double quotes (") instead of single quotes ' because that's what we use in the code.
Also, would it make sense to replace str with {"discrete", "continuous"}?
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 think a case for single-quoted strings (+ double-backticked) in docs is that Python uses single quotes for the repr of strings. But in this PR I just picked one and tried to make it consistent. I am happy to change to double.
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 tweaked the discrete vs continuous thing a bit in 78c77ed if anyone wants to check what I wrote for hue_style.
mathause
left a comment
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.
Looks good overall. There are two things I am unsure about:
- You change the signature of
ds.plot.scatteretc.. I think that's a worthwhile change but it needs a deprecation cycle - unless I am missing something? I'd suggest not doing that here but in a new PR. (I am also not entirely sure how to best do it...). - I see the
matplotlib:part of some of the references for the first time (e.g.py:meth:`matplotlib:matplotlib.figure.Figure.add_subplot\`) - this is used very inconsistently (already before). I am not sure what's correct.
|
Thanks @mathause for the review.
Yes, I suppose it would break it for anyone who was using
It works both ways (I've been building locally to check things), but I can certainly add in the |
Co-authored-by: Mathias Hauser <mathause@users.noreply.github.com>
|
The RTD is failing with Doesn't seem like it would be related to this PR, but it was passing before... |
dcherian
left a comment
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.
Thanks @zmoon. You should add a whats-new note to take credit for this. It's a great improvement.
Can we avoid the signature changes, seems like it creates more trouble than it solves.
I can put the positional The positional |
Sounds good to me. I wish I'd thought of this when implementing quiver :) |
I agree many of these could be cleaned up. They do probably need a deprecation cycle though — i.e. checking for the previous args, warning if they're supplied, and then only later removing them. |
keewis
left a comment
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.
thanks, @zmoon, and sorry for the late reply. I think we should change the signature in a new PR (using override_signature, similar to what _plot2d does), and I'm not entirely sure whether ' or " is better, but otherwise this looks good to me.
xarray/plot/dataset_plot.py
Outdated
| Variable by which to color scattered points or arrows. | ||
| hue_style: str, optional | ||
| Can be either 'discrete' (legend) or 'continuous' (color bar). | ||
| Can be either ``'discrete'`` (legend) or ``'continuous'`` (colorbar). |
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, str literals? We're currently not consistent in our code base so I think we're free to choose. If we choose to use double-backticked quoted strings (which looks better in the rendered version and slightly decreases the readability in pydoc / source code) I would vote for double quotes (") instead of single quotes ' because that's what we use in the code.
Also, would it make sense to replace str with {"discrete", "continuous"}?
| Note: if ``cmap`` is a seaborn color palette, | ||
| ``levels`` must also be specified. | ||
| colors : color-like or list of color-like, optional | ||
| colors : str or array-like of color-like, optional |
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 don't think that's right, color-like doesn't have to be a str, it can also be a tuple of floats describing RGB or RGBA values:
| colors : str or array-like of color-like, optional | |
| colors : color-like or array-like of color-like, optional |
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.
From pyplot.contour:
As a shortcut, single color strings may be used in place of one-element lists, i.e. 'red' instead of ['red'] to color all levels with the same color. This shortcut does only work for color strings, not for other ways of specifying colors.
I think I tried and found it to be the case with xarray.plot.contour as well. That is, it can be a string, or it can be an array-like of color-like values.
Edit: just checked it again. For example, colors=(0, 0, 0) raises ValueError: Invalid RGBA argument: 0, but colors=[(0, 0, 0)] or colors="black" are fine.
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.
ds.plot.scatter(..., colors=(1, 0, 0)) does not complain, but I can't get it to change the color of the scatter marks (not even with colors="r") so I might be missing something.
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.
Yeah, it seems like the colors argument is not used in ds.plot.scatter. But no error is raised, colors is just silently dropped (ax.scatter would raise AttributeError if it weren't) in most cases. I did find that you can get the marker colors to change by passing color or c with a discrete hue_style.
import xarray as xr
import numpy as np
ds = xr.tutorial.scatter_example_dataset()
ds["c"] = (ds.A.dims, np.random.choice(("r", "g", "b"), ds.A.shape))
ds.plot.scatter("A", "B", hue="c", c=(0, 0, 0)) # works but prints (doesn't raise) warning
ds.plot.scatter("A", "B", hue="c", color=(0, 0, 0)) # worksHowever, if you have a continuous hue_style, passing c is ignored (since this is done internally), and passing color raises ValueError since it conflicts with c.
It seems like at the moment, colors is really only intended to be used with contour(f) for levels, like how it is in Matplotlib. Maybe in the future it could be used to allow passing colors to be used in the color cycle for discrete hue_style, but it doesn't currently do that. So for now, maybe in the docstring we should note this current behavior (doing nothing or raising error).
actually I was able to get levels is also unused in _dsplot functions, maybe could be removedcolors to sort of work with discrete hue_style by also providing levels, but levels only makes sense for numeric type:
ds["c2"] = (ds.A.dims, np.random.choice((1, 2, 3), ds.A.shape))
ds.plot.scatter("A", "B", hue="c2", colors=["r", "g", "b"], levels=[1, 2, 3, 4]) # works (rgb)
ds.plot.scatter("A", "B", hue="c2", hue_style="discrete", colors=["r", "g", "b"]) # `colors` does nothingThere 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 think we can address this by raising appropriate errors (or implementing it) in a future PR.
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.
Ok, I am interested in working on this colors stuff. If that is ok, I will open new issue from my comment above and go from there.
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.
sounds great.
xarray/plot/dataset_plot.py
Outdated
| If provided, create a new figure for the plot with the given size: | ||
| *height* (in inches) of each plot. See also: ``aspect``. | ||
| norm : matplotlib.colors.Normalize, optional | ||
| If the ``norm`` has ``vmin`` or ``vmax`` specified, the corresponding kwarg |
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 the ``norm`` has ``vmin`` or ``vmax`` specified, the corresponding kwarg | |
| If ``norm`` has ``vmin`` or ``vmax`` specified, the corresponding kwarg |
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.
How about: the :py:class:`~matplotlib.colors.Normalize` instance?
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.
wouldn't it be easier to just refer to the object by name? I don't think we need the link because it's already in the type spec.
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.
Yeah, probably better to keep it simple.
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 guess "must be None" isn't really true, because it can also be the same value as in the norm. But maybe that isn't important. But maybe there is a better way to word this description.
| This is the default for non-numeric `hue` variables. | ||
| - for "continuous", build a colorbar | ||
| smaller arrows. | ||
| add_guide: bool, optional, default: True |
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 also control the quiverkey for quiver.
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 seems like it could make sense.
| Can be either 'discrete' (legend) or 'continuous' (color bar). | ||
| Variable by which to color scatter points or arrows. | ||
| hue_style: {'continuous', 'discrete'}, optional | ||
| How to use the ``hue`` variable: |
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.
Maybe "how to color" instead of "how to use"?
dcherian
left a comment
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 a great improvement. Thanks @zmoon!
I think we can address any remaining minor comments in a future PR.
pre-commit run --all-fileswhats-new.rstSummary:
remove(save for later PR, so can do deprec. cycle because users might have been usingaxfrom the signature of the_dsplotfunctions (unlike the_plot2dones, it shows in the built docs)axpositionally)matplotlib colormap nameNapoleon type aliasuandvfrom signature ofDataset.scatter