What happened?

The CI seems to consistently crash on test_units.py now: =========================== short test summary info =========================== FAILED xarray/tests/test_units.py::TestVariable::test_aggregation[int32-method_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestVariable::test_aggregation[int32-method_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[float64-function_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[float64-function_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[int32-function_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[int32-function_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[int32-method_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[int32-method_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_unary_operations[float64-round] - TypeError: no implementation found for 'numpy.round' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_unary_operations[int32-round] - TypeError: no implementation found for 'numpy.round' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataset::test_aggregation[int32-method_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataset::test_aggregation[int32-method_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] = 12 failed, 14880 passed, 1649 skipped, 146 xfailed, 68 xpassed, 574 warnings in 737.19s (0:12:17) = For more details: https://github.com/pydata/xarray/actions/runs/5438369625/jobs/9889561685?pr=7955

What happened?

The upstream CI has been failing for a while. Here's the latest: https://github.com/pydata/xarray/actions/runs/5501368493/jobs/10024902009#step:7:16

python Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/runner/work/xarray/xarray/xarray/__init__.py", line 1, in <module> from xarray import testing, tutorial File "/home/runner/work/xarray/xarray/xarray/testing.py", line 7, in <module> import numpy as np ModuleNotFoundError: No module named 'numpy'

Digging a little in the logs ``` Installing build dependencies: started Installing build dependencies: finished with status 'error' error: subprocess-exited-with-error

× pip subprocess to install build dependencies did not run successfully. │ exit code: 1 ╰─> [3 lines of output] Looking in indexes: https://pypi.anaconda.org/scipy-wheels-nightly/simple ERROR: Could not find a version that satisfies the requirement meson-python==0.13.1 (from versions: none) ERROR: No matching distribution found for meson-python==0.13.1 [end of output] ```

Might be some numpy problem?

Should the CI be robust enough to handle these kinds of errors? Because I suppose we would like to get the automatic issue created anyway?

Is your feature request related to a problem?

Use more up-to-date typing styles on all files. Will reduce number of imports and avoids big diffs when doing relatively minor changes because pre-commit/pyupgrade has been triggered somehow.

Related to #6240

Describe the solution you'd like

Add from __future__ import annotations on files with a lot of typing. Let pyupgrade do the rest.

Describe alternatives you've considered

No response

Additional context

No response

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.

What happened?

xr.concat removes datetime information and can't concatenate the arrays because they don't have compatible types anymore.

What did you expect to happen?

Succesful concatenation with the same type.

Minimal Complete Verifiable Example

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

month = np.arange(1, 13, 1) data = np.sin(2 * np.pi * month / 12.0)

darray = xr.DataArray(data, dims=["time"]) darray.coords["time"] = np.array([datetime(2017, m, 1) for m in month])

darray_nan = np.nan * darray.isel(**{"time": -1}) darray = xr.concat([darray, darray_nan], dim="time") ```

Relevant log output

```Python Traceback (most recent call last):

File "<ipython-input-15-31040255a336>", line 2, in <module> darray = xr.concat([darray, darray_nan], dim="time")

File "c:\users\j.w\documents\github\xarray\xarray\core\concat.py", line 244, in concat return f(

File "c:\users\j.w\documents\github\xarray\xarray\core\concat.py", line 642, in _dataarray_concat ds = _dataset_concat(

File "c:\users\j.w\documents\github\xarray\xarray\core\concat.py", line 555, in _dataset_concat combined_idx = indexes[0].concat(indexes, dim, positions)

File "c:\users\j.w\documents\github\xarray\xarray\core\indexes.py", line 318, in concat coord_dtype = np.result_type(*[idx.coord_dtype for idx in indexes])

File "<array_function internals>", line 5, in result_type

TypeError: The DType <class 'numpy.dtype[datetime64]'> could not be promoted by <class 'numpy.dtype[int64]'>. This means that no common DType exists for the given inputs. For example they cannot be stored in a single array unless the dtype is object. The full list of DTypes is: (<class 'numpy.dtype[datetime64]'>, <class 'numpy.dtype[int64]'>) ```

Anything else we need to know?

Similar to #6384.

Happens around here:

https://github.com/pydata/xarray/blob/728b648d5c7c3e22fe3704ba163012840408bf66/xarray/core/concat.py#L535

Environment

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

A while back GitHub made it so that new contributors cannot trigger GitHub Actions workflows and a maintainer has to hit "Approve and Run" every time they push a commit to their PR. This is rather annoying for both the contributor and the maintainer as the back and forth takes time.

It however seems possible to relax this constraint: https://twitter.com/metcalfc/status/1448414192285806592?t=maeChQZTSUh2Ph0YFk-hGA&s=19

Shall we relax this constraint?

ref: https://github.com/dask/community/issues/191

What happened: When interpolating a dataset with >2000 dask variables a lot of time is spent in da.unifying_chunks because da.unifying_chunks forces all variables and coordinates to a dask array. xarray on the other hand forces coordinates to pd.Index even if the coordinates was dask.array when the dataset was first created.

What you expected to happen: If the coords of the dataset was initialized as dask arrays they should stay lazy.

Minimal Complete Verifiable Example:

```python import xarray as xr import numpy as np import dask.array as da

a = np.arange(0, 2000) 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([3, 4]), dims=["time"], coords=coords ) ds0 = xr.Dataset(data_vars) ds0 = ds0.interp( time=da.array([0, 0.5, 1]), assume_sorted=True, kwargs=dict(fill_value=None), ) ```

Anything else we need to know?: Some thoughts: * Why can't coordinates be lazy? * Can we use dask.dataframe.Index instead of pd.Index when creating IndexVariables? * There's no time saved converting to dask arrays in missing.interp_func. But some time could be saved if we could convert them to dask arrays in xr.Dataset.interp before the variable loop starts. * Can we still store the dask array in IndexVariable and use a to_dask_array()-method to quickly get it? * Initializing the dataarrays will still be slow though since it still has to force the dask array to pd.Index.

Environment:

What happened: xarray feels very unresponsive when using datasets with >2000 data variables because it has to print all the 2000 variables everytime you print something to console.

What you expected to happen: xarray should limit the number of variables printed to console. Maximum maybe 25? Same idea probably apply to dimensions, coordinates and attributes as well,

pandas only shows 2 for reference, the first and last variables.

Minimal Complete Verifiable Example:

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

a = np.arange(0, 2000) b = np.core.defchararray.add("long_variable_name", a.astype(str)) data_vars = dict() for v in b: data_vars[v] = xr.DataArray( name=v, data=[3, 4], dims=["time"], coords=dict(time=[0, 1]) ) ds = xr.Dataset(data_vars)

Everything above feels fast. Printing to console however takes about 13 seconds for me:

print(ds) ```

Anything else we need to know?: Out of scope brainstorming: Though printing 2000 variables is probably madness for most people it is kind of nice to show all variables because you sometimes want to know what happened to a few other variables as well. Is there already an easy and fast way to create subgroup of the dataset, so we don' have to rely on the dataset printing everything to the console everytime?

Environment: