• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

Notes: * For duckarrays, use _dtype[_generic] * For actual np.ndarrays, use np.dtype[np.generic] * np.dtype is too specific in general and it's probably not needed in most of their array_api functions. * _DTypeBase-class in np? * Mixing dtypes from np and xp is discouraged: https://github.com/data-apis/array-api/issues/582 * Using asarray seems to be the recommended way.

What happened?

When doing operations on numpy arrays and xarray variables mypy does not understand that the output is always a xarray variable regardless of the order. See example.

What did you expect to happen?

mypy to pass for the example code.

Minimal Complete Verifiable Example

```Python import numpy as np import xarray as xr

x = np.array([1, 2, 4]) v = xr.Variable(["x"], x)

numpy first:

xv = x * v xv.values # error: "ndarray[Any, dtype[bool_]]" has no attribute "values" [attr-defined] if isinstance(xv, xr.Variable): xv.values

variable first:

vx = v * x vx.values if isinstance(vx, xr.Variable): vx.values ```

MVCE confirmation

• [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [X] Complete example — the example is self-contained, including all data and the text of any traceback.
• [X] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [X] New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output

No response

Anything else we need to know?

Seen in #7741

Environment

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

This adds a line plotter based on LineCollections, called .lines at the moment.

I wanted to replace darray.plot() with using LineCollection instead. But unfortunately due to how many cases are supported (and tested in xarray) darray.plot() will continue using plt.plot.

xref:

4820

5622

What happened?

ffill, bfill reindex etc. have tolerance arguments that also supports strings. And we test for it here:

https://github.com/pydata/xarray/blob/2120808bbe45f3d4f0b6a01cd43bac4df4039092/xarray/tests/test_groupby.py#L2016-L2025

But our typing assumes it's floats only: https://github.com/pydata/xarray/blob/2120808bbe45f3d4f0b6a01cd43bac4df4039092/xarray/core/resample.py#L69-L94

What did you expect to happen?

Since our pytests pass, mypy should pass as well.

Minimal Complete Verifiable Example

```python import numpy as np import pandas as pd

import xarray as xr

https://github.com/pydata/xarray/blob/2120808bbe45f3d4f0b6a01cd43bac4df4039092/xarray/tests/test_groupby.py#L2016

Test tolerance keyword for upsample methods bfill, pad, nearest

times = pd.date_range("2000-01-01", freq="1D", periods=2) times_upsampled = pd.date_range("2000-01-01", freq="6h", periods=5) array = xr.DataArray(np.arange(2), [("time", times)])

Forward fill

actual = array.resample(time="6h").ffill(tolerance="12h") expected = xr.DataArray([0.0, 0.0, 0.0, np.nan, 1.0], [("time", times_upsampled)]) xr.testing.assert_identical(expected, actual)

```

Environment

master

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

python import xarray as xr airtemps = xr.tutorial.open_dataset("air_temperature") airtemps.air[:200].isel(lat=10, lon=10).plot.scatter(x="time", hue="time")

Before:

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

What happened?

I'm not sure if this is a bug or a feature but I was expecting this example to work since the new coord is just a slight rewrite of the original dimension coordinate:

```python import xarray as xr

ds = xr.tutorial.open_dataset("air_temperature")

Change the first time value:

ds["air_new"] = ds.air.copy() air_new_changed = ds.air_new[{"time": 0}] * 3 ds.air_new.loc[air_new_changed.coords] = air_new_changed # Works! :)

Add a another coord along time axis and change

the first time value:

ds["air_new"] = ds.air.copy().assign_coords( {"time_float": ds.time.astype(float)} ) air_new_changed = ds.air_new[{"time": 0}] * 4 ds.air_new.loc[air_new_changed.coords] = air_new_changed # Error! :(

Traceback (most recent call last):

Cell In[25], line 5 ds.air_new.loc[air_new_changed.coords] = air_new_changed

File ~\AppData\Local\mambaforge\envs\jw\lib\site-packages\xarray\core\dataarray.py:222 in setitem dim_indexers = map_index_queries(self.data_array, key).dim_indexers

File ~\AppData\Local\mambaforge\envs\jw\lib\site-packages\xarray\core\indexing.py:182 in map_index_queries grouped_indexers = group_indexers_by_index(obj, indexers, options)

File ~\AppData\Local\mambaforge\envs\jw\lib\site-packages\xarray\core\indexing.py:144 in group_indexers_by_index raise KeyError(f"no index found for coordinate {key!r}")

KeyError: "no index found for coordinate 'time_float'" ```

It's been unclear to me what methods are necessary to implement or not. I think decorating with @abstractmethod will help with that. It's a breaking change though and it could be disruptive.

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

References: https://github.com/cvxpy/cvxpy/pull/1810

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

The docstring seems to imply that it's possible to get in-memory arrays: https://github.com/pydata/xarray/blob/4bb9d9c6df77137f05e85c7cc6508fe7a93dc0e4/xarray/backends/api.py#L732

But it doesn't seem possible because of: https://github.com/pydata/xarray/blob/4bb9d9c6df77137f05e85c7cc6508fe7a93dc0e4/xarray/backends/api.py#L899

This PR removes that or check, changes the default to chunk={}, and fixes the failing tests.

• [x] Noticed in #5689
• [ ] Closes #7792
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

• [ ] Closes #7243
• [x] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

What happened?

https://docs.xarray.dev/en/stable/internals/how-to-add-new-backend.html#indexing-examples

I believe there's a typo in the BASIC indexing support example: ```python

shall support integers

backend_array._raw_indexing_method(1, 1) ```

Should be: ```python

shall support integers

backend_array._raw_indexing_method((1, 1)) ```

Suggestion of possible fixes: * Make sure it is a typo. * Create a valid custom MyBackendArray and initialize it. So it is easier to tell if it's a typo. * Add type hinting so mypy can easier catch these errors.

What did you expect to happen?

No response

Minimal Complete Verifiable Example

No response

MVCE confirmation

• [ ] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [ ] Complete example — the example is self-contained, including all data and the text of any traceback.
• [ ] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [ ] New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output

No response

Anything else we need to know?

No response

Environment

What happened?

Any matplotlib gurus have any ideas how to nicely fit 3d plots in facetgrid? python ds = xr.tutorial.scatter_example_dataset(seed=42) fg = ds.plot.scatter(x="A", y="B", z="z", hue="y", markersize="x", row="x", col="w")

2d looks fine: python fg = ds.plot.scatter(x="A", y="B", hue="y", markersize="x", row="x", col="w")

What did you expect to happen?

No plots overlapping each other, even if rotating the plots.

Minimal Complete Verifiable Example

No response

MVCE confirmation

• [x] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [x] Complete example — the example is self-contained, including all data and the text of any traceback.
• [x] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [x] New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output

No response

Anything else we need to know?

No response

Environment

• [ ] Requires #4820
• [ ] Tests added
• [ ] Passes pre-commit run --all-files
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

Seems a waste of time to transpose 1d arrays.

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] Passes pre-commit run --all-files
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

• [x] Closes #5655
• [ ] Tests added
• [ ] Passes pre-commit run --all-files
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

Dask has a pretty nice guideline for type hinting, see https://github.com/dask/community/issues/255.

Notable for us is to avoid adding typing in docstrings to avoid duplicating information.

Cache some small properties that are rather slow to calculate but doesn't change that often.

Questions that needs to be resolved:

• [ ] Can these properties change during the lifetime of the class? If so the cache needs to be reset when that happens.

• [ ] Related to #3514
• [ ] Tests added
• [ ] Passes pre-commit run --all-files
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

Notes * Mixin classes makes it difficult to cache properties. For example ndim in NdimSizeLenMixin cannot be easily be replaced with cache_readonly.

• [x] Closes #4235
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

TODO: * markersize/linewidth should work, easy if linewidth is only defined. But the hue/linewidth combo is trickier. * Possible, see post further down for details. Should be done in dataarray version in a future PR. * hue only works with coordinates. Should it work with variables? How to do that? groupby? * Leave it for coordinates only for now. * Should lines always be sorted to avoid weird lines? * Handled in dataarray version * linewidth not shown anywhere * line plots doesn't have the nice legend_elements function that scatter has which makes it a little bit more tricky. It can still be shown in the legend though.

Adds ds.plot.line. The function wraps ax.plot which should feel pretty homely for most matplotlib users.

It was a mess getting the colorbar to work because scatter returns a mappable that colorbar can handle but plot returns a list of line2ds that it can't handle. You also can't add cmaps directly to ax.plot, so to avoid for loops I changed the default color settings instead.

Feel free to break it.

Example:

Hello,

I would like an option in da.interp()that instead of returning NaNs during extrapolation returns the data corresponding to the end of the breakpoint data set range.

One way to do this is to limit the new coordinates to the array coordinates minimum and maximum value, I did a simple example with this solution down below. I think this is a rather safe way as we are just modifying the inputs to all the various interpolation classes that xarray is using at the moment. But it does look a little weird when printing the extrapolated value, the coordinates shows the limited value instead of the requested coordinates. Maybe this can be handled elegantly somewhere in the source code?

MATLAB uses this quite frequently in their interpolation functions: * https://mathworks.com/help/simulink/ug/methods-for-estimating-missing-points.html * https://mathworks.com/help/simulink/slref/2dlookuptable.html

MCVE Code Sample

```python import numpy as np import xarray as xr

def interp(da, coords, extrapolation='clip'): """ Linear interpolation that clips the inputs to the coords min and max value.

Parameters
----------
da : DataArray
    DataArray to interpolate.
coords : dict
    Coordinates for the interpolated value.
"""
if extrapolation == 'clip':
    for k, v in da.coords.items():
        coords[k] = np.maximum(coords[k], np.min(v.values))
        coords[k] = np.minimum(coords[k], np.max(v.values))

return da.interp(coords)

Create coordinates:

x = np.linspace(1000, 6000, 4) y = np.linspace(100, 1200, 3)

Create data:

X = np.meshgrid(*[x, y], indexing='ij') data = X[0] * X[1]

Create DataArray:

da = xr.DataArray(data=data, coords=[('x', x), ('y', y)], name='data')

Attempt to extrapolate:

datai = interp(da, {'x': 7000, 'y': 375}) ```

Expected Output

python print(datai) <xarray.DataArray 'data' ()> array(2250000.) Coordinates: x float64 6e+03 y float64 375.0

Versions

Is your feature request related to a problem? Please describe. Reading attributes from h5py-files is rather slow. So instead of retrieving it immediately I wanted to create a lazy dict-class that only retrieves the attribute values when necessary. But this is difficult to achieve since xarray keeps forcing the attrs to dicts in a lot of places.

Describe the solution you'd like * Replace in https://github.com/pydata/xarray/blob/dddac11b01330791ffab4dfc72d226e71821973e/xarray/core/variable.py#L865 and https://github.com/pydata/xarray/blob/dddac11b01330791ffab4dfc72d226e71821973e/xarray/core/dataset.py#L798 with a asdict(value) function that checks if the input is a valid dict-like, if not convert to dict. Things that might be good to check: * MutableMapping * hasattr(dict_like, "copy") * isinstance(dict_like, dict) == True * Remove unneccessary conversions to dict. For example https://github.com/pydata/xarray/blob/dddac11b01330791ffab4dfc72d226e71821973e/xarray/core/merge.py#L523 should not be necessary as attrs from variables/dataarrays/datasets have already been forced to dicts when they were initialized.

Describe alternatives you've considered * One could lazify with dicts as well, for example by replacing the value with a function. This however won't look good in reprs, that's why having a convienence class is nice. * dict(LazyDict) always forces to dict, it does not let it pass through unchanged even if isinstance(LazyDict, dict) == True.

Interesting reading: https://stackoverflow.com/questions/16669367/setup-dictionary-lazily https://stackoverflow.com/questions/3387691/how-to-perfectly-override-a-dict

What happened: When interpolating datasets integer arrays are forced to floats.

What you expected to happen: To retain the same dtype after interpolation.

Minimal Complete Verifiable Example:

```python import numpy as np import dask.array as da a = np.arange(0, 2) b = np.core.defchararray.add("long_variable_name", a.astype(str)) coords = dict(time=da.array([0, 1])) data_vars = dict() for v in b: data_vars[v] = xr.DataArray( name=v, data=da.array([0, 1], dtype=int), dims=["time"], coords=coords, ) ds1 = xr.Dataset(data_vars)

print(ds1) Out[35]: <xarray.Dataset> Dimensions: (time: 4) Coordinates: * time (time) float64 0.0 0.5 1.0 2.0 Data variables: long_variable_name0 (time) int32 dask.array<chunksize=(4,), meta=np.ndarray> long_variable_name1 (time) int32 dask.array<chunksize=(4,), meta=np.ndarray>

Interpolate:

ds1 = ds1.interp( time=da.array([0, 0.5, 1, 2]), assume_sorted=True, method="linear", kwargs=dict(fill_value="extrapolate"), )

dask array thinks it's an integer array:

print(ds1.long_variable_name0) Out[55]: <xarray.DataArray 'long_variable_name0' (time: 4)> dask.array<dask_aware_interpnd, shape=(4,), dtype=int32, chunksize=(4,), chunktype=numpy.ndarray> Coordinates: * time (time) float64 0.0 0.5 1.0 2.0

But once computed it turns out is a float:

print(ds1.long_variable_name0.compute()) Out[38]: <xarray.DataArray 'long_variable_name0' (time: 4)> array([0. , 0.5, 1. , 2. ]) Coordinates: * time (time) float64 0.0 0.5 1.0 2.0

```

Anything else we need to know?: An easy first step is to also force np.float_ in da.blockwise in missing.interp_func.

The more difficult way is to somehow be able to change back the dataarrays into the old dtype without affecting performance. I did a test simply adding .astype()to the returned value in missing.interp and it doubled the calculation time.

I was thinking the conversion to floats in scipy could be avoided altogether by adding a (non-)public option to ignore any dtype checks and just let the user handle the "unsafe" interpolations.

Related: https://github.com/scipy/scipy/issues/11093

Environment: