issues

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

We encountered the issue that we should plot units as (unit) instead of [unit]. This PR enables us to do exactly this, easier to change this at the source ;)

I think setting this as a global option is the correct approach, but feel free to propose alternatives :)

Support passing instances of BackendEntryPoints as the engine argument.

Closes #8447

Then instead of passing a long list of options to the open_dataset method directly, you can also configure the entrypoint in the constructor and pass it as the engine.

It would look something like this: python engine = NetCDF4BackendEntrypoint(mode="a", clobber=False) ds = xr.open_dataset("some_file.nc", engine=engine) While this is actually even more lines of code, the main advantage is to have better discoverability of the options.

TODO:

• [x] Adapt netcdf4 backend
• [x] Adapt h5netcdf backend
• [x] Find out if h5netcdf backend should have "autoclose" and "mode" options (https://github.com/pydata/xarray/pull/8520#pullrequestreview-1769368001_)
• [x] What to do with "decode_vlen_strings" option in h5netcdf (was this deprecated?)
• [x] Adapt zarr backend
• [x] Adapt scipy backend
• [x] Adapt pydap backend
• [ ] output_grid seems to be always set to True? is this intentional, why not remove it instead?
• [x] ~verify and user_charset are non-existent in pydap?~ > I still had pydap version 3.2, in 3.4 they exist...
• [x] typing is only my first impression. Not easy if upstream libs are untyped :/
• [x] ~Adapt pynio backend~ > Won't adapt because deprecated
• [x] Fix docstrings to include init options
• [x] Check if lock=True is allowed > Not allowed, otherwise scipy backend breaks
• [ ] Change default to lock=True instead of None? Maybe a later PR?
• [ ] Rename XXXBackendEntrypoint > XXXBackend ?
• [x] ~The autoclose argument seems to do nothing?~ > Actually it is used in BaseNetCDF4Array, all good
• [x] ~Move group to open_dataset instead of backend option?~ > Its not really a decoder either. Not sure, for now leave it in the init...
• [ ] Improve _resolve_decoders_kwargs, this function has a lot of implicit assumtions? Maybe remove open_dataset_parameters alltogether?
• [x] Add tests for passing backend directly via engine argument
• [x] open_dataset now has **kwargs to support backwards compatibility. Probably we should raise if unsupported stuff is added (i.e. typos) otherwise this could be confusing? (i.e. see test in zarr that checks for deprecated auto_chunk)

• xref https://github.com/pydata/xarray/issues/8238

This is highly WIP and probably everything is broken right now... Just creating this now, so other people don't work on the same :) Feel free to continue here with me.

@pydata/xarray 1. what do we do with commonly used functions, is it ok to copy them? 2. Moving the typed ops requires a lot of functions to be added to NamedArray, is there a consensus of what we want to move? Is it basically everything? 3. Slowly the utils module is becomming a graveyard of stuff we dont want to put elsewhere, maybe we should at least move the typing stuff over to a types module.

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

This aims at making the dimenion type a generic parameter. I thought I will start with NamedArray when testing this out because it is much less interconnected.

This PR adds some typing to several abstract base classes that are used in xarray.

Most of it is working, only one major point I could not figure out:

What is the type of NDArrayMixin.array??? I would appreciate it if someone that has more insight into this would help me.

Several minor open points:

• What is the return value of ExplicitlyIndexed.__getitem__
• What is the return value of ExplicitlyIndexed.transpose
• What is the return value of AbstractArray.data
• Variable.values seems to be able to return scalar values which is incompatible with the AbstractArray definition.

Overall it seems that typing has helped to find some problems again :)

Mypy should fail for tests, I did not adopt them yet, want to solve the outstanding issues first.

I was playing around a bit with a mypy plugin and this was the best I could come up with. Unfortunately the mypy docu about the plugins is not very detailed...

This plugin makes mypy recognize the user defined accessors.

There is a quite severe bug in there (due to my lack of understanding of mypy internals probably) which makes it work only on the first run but when you change a line in your code and run mypy again it will crash... (you can delete the cache to make it work one more time again :)

Any chance that a mypy expert can figure this out? haha