-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Plots get labels from pint arrays #5561
Changes from 4 commits
ec3040e
6bb4298
04d78c5
6fee339
17c5755
48ba107
531385b
9cb2f9b
ae6e931
dc24d3f
6ce6b05
04d7b02
ee34649
552b322
1215e69
af8a1ee
e095bf0
eb7d84d
4d43f17
74c05e3
7e5e928
3f85e21
e397168
45245d0
27fc4e5
3e8cb24
f9d6370
50fdf4c
1c94a97
2d07c0f
9673cea
0d624cc
2f1ff46
afd35e2
6d33b35
eae95f5
36f3bd9
4c53790
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,10 +5,22 @@ | |
import pandas as pd | ||
import pytest | ||
|
||
try: | ||
import matplotlib.pyplot as plt | ||
except ImportError: | ||
pass | ||
|
||
import xarray as xr | ||
from xarray.core import dtypes, duck_array_ops | ||
|
||
from . import assert_allclose, assert_duckarray_allclose, assert_equal, assert_identical | ||
from . import ( | ||
assert_allclose, | ||
assert_duckarray_allclose, | ||
assert_equal, | ||
assert_identical, | ||
requires_matplotlib, | ||
) | ||
from .test_plot import PlotTestCase | ||
from .test_variable import _PAD_XR_NP_ARGS | ||
|
||
pint = pytest.importorskip("pint") | ||
|
@@ -5564,3 +5576,29 @@ def test_merge(self, variant, unit, error, dtype): | |
|
||
assert_units_equal(expected, actual) | ||
assert_equal(expected, actual) | ||
|
||
|
||
@requires_matplotlib | ||
class TestPlots(PlotTestCase): | ||
def test_units_in_line_plot_labels(self): | ||
arr = np.linspace(1, 10, 3) * unit_registry.Pa | ||
# TODO make coord a Quantity once unit-aware indexes supported | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. shouldn't it be possible to specify a non-dimensional coordinate with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The point was that I want this test to eventually test labels on both the x and y axes, but at the moment pint is only involved with the y axis, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. that's right. I meant to implement this by converting the dimension coordinate to a non-dimension coordinate: x_coord = xr.DataArray(
np.linspace(1, 3, 3) * unit_registry.m, dims="x"
)
da = xr.DataArray(data=arr, dims="x", coords={"x_coord": x_coord}, name="pressure")
da.plot.line(x="x_coord") There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I try that I still get a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That seems like a bug. open an issue for it so we don't forget? |
||
x_coord = xr.DataArray( | ||
np.linspace(1, 3, 3), dims="x", attrs={"units": "meters"} | ||
) | ||
da = xr.DataArray(data=arr, dims="x", coords={"x": x_coord}, name="pressure") | ||
|
||
da.plot.line() | ||
|
||
ax = plt.gca() | ||
assert ax.get_ylabel() == "pressure [pascal]" | ||
assert ax.get_xlabel() == "x [meters]" | ||
|
||
def test_units_in_2d_plot_labels(self): | ||
arr = np.ones((2, 3)) * unit_registry.Pa | ||
da = xr.DataArray(data=arr, dims=["x", "y"], name="pressure") | ||
|
||
fig, (ax, cax) = plt.subplots(1, 2) | ||
ax = da.plot.contourf(ax=ax, cbar_ax=cax, add_colorbar=True) | ||
|
||
assert cax.get_ylabel() == "pressure [pascal]" |
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 this is the reason for the failures (see #4751 (comment)): we import
pint
here, butpint
also tries to importxarray
for type checking. Normally, the circular import would be an error butpytest
silences that, apparently, resulting in a partially imported module.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.
Do you think this explains the failures in #5568 too?
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.
Looking at this properly I see what you mean now. So is this PR just stuck then? Why can we not just check the name rather than the explicit type within xarray (for now at least)?
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 could import
pint
in the functions that usepint_array_type
for now (or add a_get_pint_array_type
function topycompat
and call it whereverpint_array_type
would be used), and I'll try to getpint
to not importxarray
(because ideally it should not care about what wraps it). Not sure if that's possible, though.The best long term fix would be to figure out dask/dask#6635
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 It would be good to hear your thoughts on that over on the Pint issue tracker. Right now, to maintain the type casting hierarchy, libraries with duck arrays have to either define a list of types they can wrap (and prohibit all others) or a list which are meant to wrap it (and allow wrapping any other). Pint went with the latter since it was the safest approach as a type high on the graph (https://pint.readthedocs.io/en/stable/numpy.html#Technical-Commentary), but I suppose that if that was problematic, it could be flipped around to a list of allowed types to wrap (with a breaking change), as Dask ended up doing (dask/dask#6393).
But, definitely, this ad hoc approach to the type casting hierarchy will continue to be problematic until dask/dask#6635 is resolved definitely.
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.
It would be really nice to fix this properly (and I will bring it up in the xarray dev call now), but for this PR then your suggestion seems to work nicely on #5568 @keewis , thanks.