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-1138997020,https://api.github.com/repos/pydata/xarray/issues/6142,1138997020,IC_kwDOAMm_X85D47cc,5635139,2022-05-26T20:27:19Z,2022-05-26T20:27:19Z,MEMBER,"Ah, that's a good case @headtr1ck . So `str | Iterable[Hashable]` works when one is checked before the other, but not when they're required to be disjoint, like an `overload`.
I don't have an immediate solution in mind unfortunately. I'm not sure having different return types is a great design in general, though I can see the logic for it in this case...","{""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-1132117191,https://api.github.com/repos/pydata/xarray/issues/6142,1132117191,IC_kwDOAMm_X85DerzH,5635139,2022-05-19T19:28:04Z,2022-05-19T19:28:04Z,MEMBER,"> 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]`?
I spent a non-trivial amount of time on this a year ago or so — my understanding is that `Mapping` was _not_ covariant in its keys, exactly as you point out.
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?
e.g. https://mypy-play.net/?mypy=latest&python=3.10&gist=a3ea9f6fce5a678803bd7563a54cd9ca
> See https://mypy-play.net/?mypy=latest&python=3.10&gist=b2c27a5ca4aad9e8ce63cd74dc4032b0
Very cool! I didn't even know about this.","{""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-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-1116791799,https://api.github.com/repos/pydata/xarray/issues/6142,1116791799,IC_kwDOAMm_X85CkOP3,5635139,2022-05-04T00:21:34Z,2022-05-04T00:21:34Z,MEMBER,"> there are so many inconsistencies that I even wonder if it is possible to use anything but strings in ""production"".
I would have thought this is indeed the case. I think we're quite open to adjusting this so that it works, but it would probably needs some work, including defining common patterns — e.g. the title of this issue is a good approach
> Apart from arguments randomly being called `dim` or `dims`
I also think we'd be up for reforming this! Generally this is the first arg and so only used positionally, but it still makes sense to have them consistent.","{""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
https://github.com/pydata/xarray/issues/6142#issuecomment-1007746043,https://api.github.com/repos/pydata/xarray/issues/6142,1007746043,IC_kwDOAMm_X848EPv7,10194086,2022-01-07T21:15:23Z,2022-01-07T21:15:23Z,MEMBER,"I agree this is confusing, what is meant here is to use a tuple as the name for _one_ dimension. An example:
```python
ds = xr.Dataset({""x"": ([(""a"", ""b"")], [1])})
print(ds)
print(f""{ds.x.dims = }"")
```
```python
Dimensions: (('a', 'b'): 1)
Dimensions without coordinates: ('a', 'b')
Data variables:
x (('a', 'b')) int64 1
ds.x.dims = (('a', 'b'),)
```
---
I found the issue again where we discussed that we want to keep `dim: Hashable`: #4821","{""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-1007729786,https://api.github.com/repos/pydata/xarray/issues/6142,1007729786,IC_kwDOAMm_X848ELx6,35968931,2022-01-07T20:46:40Z,2022-01-07T20:46:40Z,MEMBER,"> We need to be careful typing functions where only one dim is allowed, e.g. xr.concat, which should probably set dim: Hashable (and make sure it works).
Sorry, I don't understand this - if I want to type hint `concat` so that no-one can pass more than one dim, isn't my only option to type hint it as `str`? Because if I type hint it as `Hashable` they could pass `(""x"", ""y"")`, which is two dims? Maybe I'm not following properly...","{""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-1007250588,https://api.github.com/repos/pydata/xarray/issues/6142,1007250588,IC_kwDOAMm_X848CWyc,10194086,2022-01-07T09:13:21Z,2022-01-07T09:13:21Z,MEMBER,"> This will still work as two dims, since having `str | Iterable[Hashable]` rather than `Hashable | Iterable[Hashable]` means it will fail the first check. So if someone really wants a single dim as `(""x"", ""y"")`, they can pass `((""x"", ""y""),)`.
Yes, I think that is the gist of the proposal. I also think that it is quite elegant.
> Does this mean that this would be confusion free?
I think it would be relatively unambiguous but not necessarily entirely confusion free for the user (""Why is the type of a single dim more restricted than of several dimensions?""). Maybe this warrants an entry in our FAQ or somewhere? Also we need to go over our code and update our typing and make sure stuff like `xr.DataArray([1], dims=[(""x"", ""y"")]` works as proposed here.","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1094725752
https://github.com/pydata/xarray/issues/6142#issuecomment-1006622944,https://api.github.com/repos/pydata/xarray/issues/6142,1006622944,IC_kwDOAMm_X847_9jg,5635139,2022-01-06T14:13:58Z,2022-01-06T14:13:58Z,MEMBER,"Thanks for writing this out. I realize something clever about the proposal:
Our very first line of code in the docs passes dims as a tuple `dims=(""x"", ""y"")`: https://xarray.pydata.org/en/stable/getting-started-guide/quick-overview.html#create-a-dataarray
This will still work as two dims, since having `str | Iterable[Hashable]` rather than `Hashable | Iterable[Hashable]` means it will fail the first check. So if someone really wants a single dim as `(""x"", ""y"")`, they can pass `((""x"", ""y""),)`.
Does this mean that this would be confusion free?","{""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-1006104672,https://api.github.com/repos/pydata/xarray/issues/6142,1006104672,IC_kwDOAMm_X8479_Bg,1217238,2022-01-05T21:48:05Z,2022-01-05T21:48:05Z,MEMBER,"> @shoyer - did I get this right from the discussion?
Yes, this was my suggestion.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1094725752