issue_comments

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...

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.

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.

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 <xarray.Dataset> 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

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...

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.

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?

@shoyer - did I get this right from the discussion?

Yes, this was my suggestion.