As I'm a developing my custom chunk manager, I'm often checking out between my development branch and production branch breaking the entrypoint.

This made xarray impossible to import unless I re-ran pip install -e . -vv which is somewhat tiring.

This should help xarray be more resilient in other software's bugs in case they install malformed entrypoints

Example:

```python

from xarray.core.parallelcompat import list_chunkmanagers

list_chunkmanagers() <ipython-input-3-19326f4950bc>:1: UserWarning: Failed to load entrypoint MyChunkManager due to No module named 'my.array._chunkmanager'. Skipping. list_chunkmanagers() {'dask': <xarray.core.daskmanager.DaskManager at 0x7f5b826231c0>} ```

Thank you for considering.

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

This is mostly a quality of life thing for developers, I don't see this as a user visible change.

For example, you just broke cubed

https://github.com/xarray-contrib/cubed-xarray/blob/main/cubed_xarray/cubedmanager.py#L15

Not sure how much you care, it didn't seem like anybody other than me ever tried this module on github...

• [ ] 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

xref: https://github.com/pydata/xarray/issues/8733

Its somewhat annoying to get warnings that point to a line within a library where the warning is issued. It really makes it unclear what one needs to change.

This points to the user's access of the dims attribute.

• [ ] 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

I admit this is a super micro optimization but it avoids in certain cases the creation of a tuple, and a call to len on it.

I hit this as I was trying to understand why Variable indexing was so much slower than numpy indexing. It seems that bounds checking in python is just slower than in C.

Feel free to close this one if you don't want this kind of optimization.

• [ ] 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

Not too sure i have the bandwidth to complete this seeing as cftime and datetime don't have nanoseconds, but maybe it can help somebody.

• [x] Closes #4183
• [x] Tests added
• [ ] Passes isort . && black . && mypy . && flake8
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

Using .data accidentally tries to load the whole lazy arrays into memory.

Sad.

• [ ] 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

ZipStores aren't always closed making it hard to use them as fluidly as regular zarr stores.

• [ ] Closes #xxxx
• [x] Tests added
• [x] Passes isort . && black . && mypy . && flake8 # master doesn't pass black
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

It seems that the relevant issue was fixed in 2.10.0 https://github.com/h5py/h5py/commit/466181b178c1b8a5bfa6fb8f217319e021f647e0

I'm not sure how far back you want to fix things. I'm hoping to test this on the CI.

I found this since I've been auditing slowdowns in our codebase, which has caused me to review much of the reading pipeline.

Do you want to add a test for h5py>=2.10.0? Or can we assume that users won't install things together. https://pypi.org/project/h5py/2.10.0/

I could for example set the backend to not be available if a version of h5py that is too old is detected. One could alternatively, just keep the code here.

• [ ] 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

Taken from discussions in https://github.com/pydata/xarray/issues/7224#issuecomment-1292216344

Thank you @Illviljan

• [ ] 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

I don't think this affects what is displayed that is determined by param_names

• [ ] 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

In relation to my other PR.

Without this PR

With the early return

xref: https://github.com/pydata/xarray/pull/7221

• [ ] 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

We've been trying to understand why our code is slow. One part is that we use xarray.Datasets almost like dictionaries for our data. The following code is quite common for us

python import xarray as xr dataset = xr.Dataset() dataset['a'] = 1 dataset['b'] = 2

However, through benchmarks, it became obvious that the merge_core method of xarray was causing alot of slowdowns. main branch:

With this merge request:

```python from tqdm import tqdm import xarray as xr from time import perf_counter import numpy as np

N = 1000

Everybody is lazy loading now, so lets force modules to get instantiated

dummy_dataset = xr.Dataset() dummy_dataset['a'] = 1 dummy_dataset['b'] = 1 del dummy_dataset

time_elapsed = np.zeros(N) dataset = xr.Dataset()

for i in tqdm(range(N)): time_start = perf_counter() dataset[f"var{i}"] = i time_end = perf_counter() time_elapsed[i] = time_end - time_start

%%

from matplotlib import pyplot as plt

plt.plot(np.arange(N), time_elapsed * 1E3, label='Time to add one variable') plt.xlabel("Number of existing variables") plt.ylabel("Time to add a variables (ms)") plt.ylim([0, 50]) plt.grid(True) ```

• [ ] 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

xref: https://github.com/pydata/xarray/pull/7221

• [ ] 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

I was auditing the import time of my software and found that distributed added a non insignificant amount of time to the import of xarray:

Using tuna, one can find that the following are sources of delay in import time for xarray:

To audit, one can use the the command python -X importtime -c "import numpy as np; import pandas as pd; import dask.array; import xarray as xr" 2>import.log && tuna import.lo The command as is, breaks out the import time of numpy, pandas, and dask.array to allow you to focus on "other" costs within xarray. Main branch:

Proposed:

One would be tempted to think that this is due to xarray.testing and xarray.tutorial but those just move the imports one level down in tuna graphs.

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

Admittedly i had a pretty broken environment (I manually uninstalled C dependencies for python packages installed with conda), but I still expected xarray to "work" with a different backend.

I hope the comments in the code explain why ImportError is preferred to ModuleNotFoundError.

Thank you for considering.

• [ ] 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

• [ ] Related to #3815
• [ ] Tests added
• [ ] Passes isort -rc . && black . && mypy . && flake8
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

Previously, this would raise a:

FutureWarning: iteration over an xarray.Dataset will change in xarray v0.11 to only include data variables, not coordinates. Iterate over the Dataset.variables property instead to preserve existing behavior in a forwards compatible manner.

• [ ] Closes #xxxx (remove if there is no corresponding issue, which should only be the case for minor changes)
• [ ] Tests added (for all bug fixes or enhancements)
• [ ] Tests passed (for all non-documentation changes)
• [ ] 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)