html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/6142#issuecomment-1166509214,https://api.github.com/repos/pydata/xarray/issues/6142,1166509214,IC_kwDOAMm_X85Fh4Se,43316012,2022-06-26T11:57:39Z,2022-06-26T11:57:39Z,COLLABORATOR,See https://github.com/python/typing/issues/256 as reference for this problem.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1094725752
https://github.com/pydata/xarray/issues/6142#issuecomment-1137623370,https://api.github.com/repos/pydata/xarray/issues/6142,1137623370,IC_kwDOAMm_X85DzsFK,43316012,2022-05-25T17:40:16Z,2022-05-25T17:40:16Z,COLLABORATOR,"I have encountered another problem that is related to this:
`DataArray.argmin`s `dim` argument is: `Hashable | Sequence[Hashable] | None`, where None is a special case that will apply over all dimensions.
So I tried to overload this:
```python
@overload
def argmin(
self,
dim: Hashable,
*,
axis: int | None = None,
keep_attrs: bool | None = None,
skipna: bool | None = None,
) -> DataArray:
...
@overload
def argmin(
self,
dim: Sequence[Hashable] | None = None,
axis: int | None = None,
keep_attrs: bool | None = None,
skipna: bool | None = None,
) -> dict[Hashable, DataArray]:
...
```
but mypy complains:
>Overloaded function signatures 1 and 2 overlap with incompatible return types [misc]
I suspect that this is due to the fact that None is actually Hashable and therefore a valid dimension.
Unfortunately, using this proposal of `str | Sequence[Hashable]` won't work since `str` is actually a Sequence of Hashables... (I know that this proposal is meant for functions that always expect multiple dims and the str is only a lazy mans shortcut)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1094725752
https://github.com/pydata/xarray/issues/6142#issuecomment-1132147701,https://api.github.com/repos/pydata/xarray/issues/6142,1132147701,IC_kwDOAMm_X85DezP1,43316012,2022-05-19T20:05:43Z,2022-05-19T20:05:43Z,COLLABORATOR,"> But I'm also not sure we lose anything with `Mapping[Any, foo]` — the key needs to be `Hashable` anyway. I don't have a strong objection, but do we gain anything?
Wow, totally forgot about this. Then you are right, Any as key is totally ok.
Although if I am not mistaken, one could define a custom Mapping class that allows non-hashable keys, this is quite a niche use case and there are more urgent things to type, like this issue.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1094725752
https://github.com/pydata/xarray/issues/6142#issuecomment-1132105430,https://api.github.com/repos/pydata/xarray/issues/6142,1132105430,IC_kwDOAMm_X85Deo7W,43316012,2022-05-19T19:14:41Z,2022-05-19T19:20:28Z,COLLABORATOR,"Only remotely related to this issue, but would it help to type the dimension (or variable names etc) Mappings with covariant Hashable keys to prevent the issue that `{""a"":1}` is incompatible with `Mapping[Hashable, Any]`?
Something like:
```python
Hashable_co = TypeVar(""Hashable_co"", bound=Hashable, covariant=True)
Mapping[Hashable_co, Any]
```
Same for lists etc. (Or use Sequences which are already covariant, as opposed to lists)
I am not an expert on variance in types and don't know if this would break things, but at least in my tests mypy did not complain when using `dict[str, str]`.
See https://mypy-play.net/?mypy=latest&python=3.10&gist=b2c27a5ca4aad9e8ce63cd74dc4032b0","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1094725752
https://github.com/pydata/xarray/issues/6142#issuecomment-1116686433,https://api.github.com/repos/pydata/xarray/issues/6142,1116686433,IC_kwDOAMm_X85Cj0hh,43316012,2022-05-03T21:39:07Z,2022-05-03T21:39:07Z,COLLABORATOR,"I was just looking through the code a bit and I must say that the usage of dimension arguments is far from harmonized in the code....
Apart from arguments randomly being called `dim` or `dims`, there are so many inconsistencies that I even wonder if it is possible to use anything but strings in ""production"".
* some parts of the code claim that hashable is allowed but then check explicitly for str else `tuple(dims)` which would straight up fail with a custom hashable class.
* Some parts do the exact opposite, they check for iterable and not str first.
At least internally most objects use `tuple[Hashable, ...]` for dims.
The lazy shortcut to allow a single str is making this more complicated than one might think (but I have to admit, I use it all the time).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1094725752
https://github.com/pydata/xarray/issues/6142#issuecomment-1116434282,https://api.github.com/repos/pydata/xarray/issues/6142,1116434282,IC_kwDOAMm_X85Ci29q,43316012,2022-05-03T18:39:46Z,2022-05-03T18:39:46Z,COLLABORATOR,"In case you are missing a use case for tuples as dimension/variable names:
We have a system with two detectors, lets call them ""a"" and ""b"".
Both take 2D images with dimensions ""x"" and ""y"" but different sizes.
Now instead of calling the dimensions ""x_a"", ""y_a"", ""x_b"", ""y_b"" we call them (""x"", ""a"") etc.
This makes looking for dimensions etc. more consistent (Even better with a custom hashable dimension class).","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1094725752