issue_comments

See https://github.com/python/typing/issues/256 as reference for this problem.

I have encountered another problem that is related to this: DataArray.argmins 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)

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.

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

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

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