issues

• [x] Tests added

This was a minor issue that came up at the Dask BOF. Currently if the key of chunks dict isn't included in the dims then it gets silently ignored. This PR makes xarray raise an error instead.

I'm not sure if this is the right place to put this change. So just let me know if it should go somewhere else.

I changed an existing test. I am pretty sure it was not intentionally using a key that isn't in the dims.

What is your issue?

I just realized that the difference between .load() and .compute() is that .load() operates inplace and .compute() returns a new xarray object.I have 2 suggestions for how this could be clearer:

1. Docs: the API docs for each method could reference the other.
2. Code: this might be too big a change, but maybe .load() should not return anything. Consider this example from pandas: ```python import pandas as pd

df = pd.DataFrame({"air": []}) df.rename({"air": "foo"}, axis=1, inplace=True) # returns None since df is renamed inplace `` this matches the behavior of inplace actions in Python itself likelist.appendordict.update. This would be a major breaking change though, and it might be easier to just remove.load()` entirely.

• [x] Tests added

This came up in the tutorial and I was wondering if the error could be made a little clearer. Not sure if the error message should hint that a user might want to use method.

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

arr = xr.DataArray( data=np.arange(48).reshape(4, 2, 6), dims=("u", "v", "time"), coords={ "u": [-3.2, 2.1, 5.3, 6.5], "v": [-1, 2.6], "time": pd.date_range("2009-01-05", periods=6, freq="M"), }, ) arr.sel(u=5, time="2009-04-28") # I removed method="nearest" ```

Before this PR:

python-traceback ... KeyError: 5.0

After this PR:

python-traceback ... KeyError: "not all values found in index 'u'. Did you mean to set `method=`?"

• [x] Discussed in #1736
• [x] Tests added
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

Not sure if this is the right approach @snowman2

• [x] Closes #3806
• [x] Passes isort -rc . && black . && mypy . && flake8
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

I just wanted to open this to discuss turning the repr_html on by default. This PR https://github.com/pydata/xarray/pull/3425 added it as a style option, but I suspect that more people will use if it is on by default. Does that seem like a reasonable change?

Since pandas has implemented entry_points based plotting backends, it seems reasonable that xarray would do the same. This would make it even easier to produce holoviews plots (rendered in bokeh via hvplot), by using the plot method rather than by importing hvplot directly.

Example

```python import xarray as xr air = xr.tutorial.open_dataset('air_temperature').load().air xr.options.plotting.backend = 'holoviews'

air.isel(time=500).plot() ```

• [ ] Closes #xxxx
• [ ] Tests added
• [x] Passes black . && mypy . && flake8
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

Follow on to #3425 to include support for jupyterlab dark theme. Note that this includes slight color changes. The most striking of which is that in jupyterlab light and regular notebook the even rows are white like the background.

Jlab dark

Jlab light

notebook

This PR supersedes #1820 - see that PR for original discussion. See this gist to try out the new MultiIndex and options functionality.

• [x] Closes #1627, closes #1820
• [x] Tests added
• [x] Passes black . && mypy . && flake8
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

TODO:

• [x] Add support for Multi-indexes
• [x] Probably good to have some opt-in or fail back system in case where we (or users) know that the rendering will not work
• [x] Add some tests

• [ ] Closes #xxxx
• [x] Tests added
• [x] Passes black . && mypy . && flake8
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

Follow-on to https://github.com/pydata/xarray/pull/3425 to make html_repr work with dtypes like '<U5'

When reading from multiple files, sometimes there is information encoded in the filename. For example in these grib files the time: ./ST4.2018092500.01h, ./ST4.2018092501.01h. It seems like a generally useful thing would be to allow the passing of a kwargs (such as path_as_coord or something) that would define a set of coords with one for the data from each file.

I think the code change would be small:

python if path_as_coord: ds = ds.assign_coords(path=file_name)

In use it would be like:

```python

xr.open_mfdataset(['./ST4.2018092500.01h', './ST4.2018092501.01h'], engine='pynio', concat_dim='path') <xarray.Dataset> Dimensions: (x: 881, y: 1121, time: 2) Coordinates: lat (x, y) float32 23.116999 ... 45.618984 lon (x, y) float32 -119.023 ... -59.954613 * path (path) <U20 './ST4.2018092500.01h' './ST4.2018092501.01h' Dimensions without coordinates: x, y Data variables: var_0 (time, x, y) float32 dask.array<shape=(2, 881, 1121), chunksize=(1, 881, 1121)> var_1 (time, x, y) float32 dask.array<shape=(2, 881, 1121), chunksize=(1, 881, 1121)> ```

For context I have implemented something similar in dask: https://github.com/dask/dask/pull/3908

• [x] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

This is a PR for the follow on work set out in https://github.com/pydata/xarray/pull/2375#issuecomment-415227870

• [x] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

Not sure if this is a desirable change but I thought it could be easily discussed as a PR. Just for context I was looking at flattening spatial data for machine learning pipelines and then reshaping after the output had been acquired.

I have a NxM array called b and am flattening it like:

python flat_input = b.stack(z=('y', 'x'))

Then I use that flat_input in my ML pipeline and get back an np.array (called output) which I want to unstack using all the metadata that went into stacking my original NxM array b.

python xr.full_like(flat_input, output).unstack(dim='z')

This PR just makes the dim argument optional in unstack so that we can use

python xr.full_like(flat_input, output).unstack()

As a follow on PR I was thinking of making a function called xr.unstack_like(other: xr.DataArray|xr.Dataset, data: array_like) to encompass this functionality. A couple questions:

1) Would something like xr.unstack_like be desirable? 2) Should we be using xr.full_like in this way? The documentation in xarray and numpy only mentions scalars, but arrays work fine in both. If this is a supported behavior I could add docs, and if not perhaps a copy and overwrite is a better approach?

Here is a gist of the workflow using a tweaked datashader example and datashader example data https://gist.github.com/jsignell/79a6cf2da5c1458211d9dcf34d4417df

Just a docs change. Updated instructions for installing PyNIO to use conda-forge.

Makes it easier to dump to json (after conversation on #917)

After the conversation #432

netcdf4python supports milliseconds and microseconds:

https://github.com/Unidata/netcdf4-python/commit/22d439d6d3602171dc2c23bca0ade31d3c49ad20

would it be possible to support in X-ray?