id,node_id,number,title,user,state,locked,assignee,milestone,comments,created_at,updated_at,closed_at,author_association,active_lock_reason,draft,pull_request,body,reactions,performed_via_github_app,state_reason,repo,type
2021585639,PR_kwDOAMm_X85g77tr,8503,Add option to define custom format of units in plots,43316012,open,0,,,5,2023-12-01T21:09:18Z,2024-02-02T22:09:11Z,,COLLABORATOR,,0,pydata/xarray/pulls/8503,"<!-- Feel free to remove check-list items aren't relevant to your change -->

- [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 :)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8503/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
1901722232,PR_kwDOAMm_X85anII7,8204,Rewrite typed_ops,43316012,closed,0,,,5,2023-09-18T20:51:22Z,2023-09-26T19:00:49Z,2023-09-25T04:43:54Z,COLLABORATOR,,0,pydata/xarray/pulls/8204,"<!-- Feel free to remove check-list items aren't relevant to your change -->

- [x] Related to #7780
- [x] Tests added
- [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst`
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8204/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
1548948097,I_kwDOAMm_X85cUxKB,7457,Typing of internal datatypes,43316012,open,0,,,5,2023-01-19T11:08:43Z,2023-01-19T19:49:19Z,,COLLABORATOR,,,,"### Is your feature request related to a problem?

Currently there is no static typing of the underlying data structures used in `DataArray`s.
Simply running 
`reveal_type(da.data)` returns `Any`.

Adding static typing support to that is unfortunately non-trivial since xarray supports a wide variety of duck-types.

This also comes with internal typing difficulties.



### Describe the solution you'd like

I think the way to go is making the `DataArray` class generic in it's underlying data type.
Something like `DataArray[np.ndarray]` or `DataArray[dask.array]`.

The implementation would require a TypeVar that is bound to some minimal required Protocol for internal consistency (I think at least it needs `dtype` and `shape` attributes).

Datasets would have to be typed the same way, this means only one datatype for all variables is possible, when you mix it it will fall back to the common ancestor which will be the before mentioned protocol. This is basically the same restriction that a dict has.

 Now to the main issue that I see with this approach:
I don't know how to type coordinates. They have the same problems than mentioned above for Datasets.
I think it is very common to have dask arrays in the variables but simple numpy arrays in the coordinates, so either one excludes them from the typing or in such cases the common generic typing falls back to the protocol again.
Not sure what is the best approach here.

### Describe alternatives you've considered

Since the most common workflow for beginners and intermediate-advanced users is to stick with the DataArrays themself and never touch the underlying data, I am not sure if this change is as beneficial as I want it to be. Maybe it just complicates things and leaving it as `Any` is easier to solve for advanced users that then have to cast or ignore this.

### Additional context

It came up in this discussion: 
https://github.com/pydata/xarray/pull/7020#discussion_r972617770_","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/7457/reactions"", ""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue
1388372090,I_kwDOAMm_X85SwOB6,7094,Align typing of dimension inputs,43316012,open,0,,,5,2022-09-27T20:59:17Z,2022-10-13T18:02:16Z,,COLLABORATOR,,,,"### What is your issue?

Currently the input type for ""one or more dims"" is changing from function to function.
There are some open PRs that move to `str | Iterable[Hashable]` which allows the use of tuples as dimensions.

Some changes are still required:
- [ ] Accept None in all functions that accept dims as default, this would simplify typing alot (see https://github.com/pydata/xarray/pull/7048#discussion_r973813607)
- [ ] Check if we can always include ellipsis ""..."" in dim arguments (see https://github.com/pydata/xarray/pull/7048#pullrequestreview-1111498309)
- [ ]  `Iterable[Hashable]` includes sets, which do not preserve the ordering (see https://github.com/pydata/xarray/pull/6971#discussion_r981166670).
This means we need to distinguish between the cases where the order matters (constructor, transpose etc.) and where it does not (drop_dims, reductions etc.).
Probably this needs to be typed as a `str | Sequence[Hashable]` (a numpy.ndarray is not a Sequence, but who uses this for dimensions anyway?).","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/7094/reactions"", ""total_count"": 5, ""+1"": 4, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue
1292284929,I_kwDOAMm_X85NBrQB,6749,What should `Dataset.count` return for missing dims?,43316012,open,0,,,5,2022-07-03T11:49:12Z,2022-07-14T17:27:23Z,,COLLABORATOR,,,,"### What is your issue?

When using a dataset with multiple variables and using `Dataset.count(""x"")` it will return ones for variables that are missing dimension ""x"", e.g.:
```python
import xarray as xr
ds = xr.Dataset({""a"": (""x"", [1, 2, 3]), ""b"": (""y"", [4, 5])})
ds.count(""x"")
# returns:
# <xarray.Dataset>
# Dimensions:  (y: 2)
# Dimensions without coordinates: y
# Data variables:
#     a        int32 3
#     b        (y) int32 1 1
```
I can understand why ""1"" can be a valid answer, but the result is probably a bit philosophical.

For my usecase I would like it to return an array of `ds.sizes[""x""]` / 0. I think this is also a valid return value, considering the broadcasting rules, where the size of the missing dimension is actually known in the dataset.


Maybe one could make this behavior adjustable with a kwarg, e.g. ""missing_dim_value: {int, ""size""}, default 1. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6749/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue
1248463174,PR_kwDOAMm_X844drcZ,6637,Improved DataArray typing,43316012,closed,0,,,5,2022-05-25T17:54:54Z,2022-05-29T14:02:22Z,2022-05-27T16:03:10Z,COLLABORATOR,,0,pydata/xarray/pulls/6637,"- [x] Tests added

This PR improves typing of `DataArray` class methods.
Main change is that `T_DataArray` is used whenever possible.

I have left everything untouched that would cause problems with mypy (there are some mypy bugs) or require larger typing efforts in other areas.

Main problems are `argmin` and `argmax`.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6637/reactions"", ""total_count"": 3, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 3, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
1245726154,I_kwDOAMm_X85KQEXK,6632,Literal type of engine argument incompatible with custom backends,43316012,closed,0,,,5,2022-05-23T21:40:14Z,2022-05-28T10:29:16Z,2022-05-28T10:29:16Z,COLLABORATOR,,,,"### What is your issue?

In the recent typing improvements the `engine` argument for `open_dataset` was changed from Str to a Literal of xarrays internal engines.
This will cause problems for all third party backend plugins.

We have several possibilities:

1. I don't know if there is a way to know installed backends at type checking time. Then we could add this support. (I doubt this is possible seeing how dynamic these imports are)
2. Is it possible for these plugins to tell type checkers that their engine is valid, i.e. change the type signature of xarrays function? Then we should add a how-to in the docu.
3. Else we should probably revert to using Str.

Any typing experts here that could help?","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6632/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue
1236356209,PR_kwDOAMm_X8431neg,6612,Typing for open_dataset/array/mfdataset and to_netcdf/zarr,43316012,closed,0,,,5,2022-05-15T18:09:15Z,2022-05-19T16:08:07Z,2022-05-17T19:32:01Z,COLLABORATOR,,0,pydata/xarray/pulls/6612,"<!-- Feel free to remove check-list items aren't relevant to your change -->

- [x] Closes #5382 

Mypy is not able to compute the overloads of to_netcdf properly (too many Unions).
I had to add some `# type: ignore`

I am not sure about the types of
* `concat_dim`
* `combine_attrs`: the `Callable` part is still with Anys","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6612/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull