Fix mypy errors

[jsignell]

This should get mypy tests passing on CI

[jsignell]

Well it looks like mypy is probably passing but Stubtest is not:

error: xarray.core.variable.ArrayLike is not a Union
Stub: in file /home/runner/work/xarray/xarray/xarray/core/variable.py:168
_collections_abc.Buffer | numpy._typing._array_like._SupportsArray[numpy.dtype[Any]] | numpy._typing._nested_sequence._NestedSequence[numpy._typing._array_like._SupportsArray[numpy.dtype[Any]]] | builtins.complex | builtins.bytes | builtins.str | numpy._typing._nested_sequence._NestedSequence[builtins.complex | builtins.bytes | builtins.str]
Runtime:
ArrayLike

Found 1 error (checked 3 modules)

@kkollsga any ideas on that one?

[jsignell]

mypy hates reassigning a new value to an existing var. We can get around this by typing expected more loosely, by not using the word expected (like I'm doing here), or by just not type checking the tests.

[jsignell]

superseded by #11211

[kkollsga]

Well it looks like mypy is probably passing but Stubtest is not:

error: xarray.core.variable.ArrayLike is not a Union
Stub: in file /home/runner/work/xarray/xarray/xarray/core/variable.py:168
_collections_abc.Buffer | numpy._typing._array_like._SupportsArray[numpy.dtype[Any]] | numpy._typing._nested_sequence._NestedSequence[numpy._typing._array_like._SupportsArray[numpy.dtype[Any]]] | builtins.complex | builtins.bytes | builtins.str | numpy._typing._nested_sequence._NestedSequence[builtins.complex | builtins.bytes | builtins.str]
Runtime:
ArrayLike

Found 1 error (checked 3 modules)

@kkollsga any ideas on that one?

Hi, With #11211 this is resolved now, with the variable.py change from from numpy.typing import ArrayLike to qualified np.typing.ArrayLike access.

The reason this works is that numpy 2.4+ defines ArrayLike as a TypeAliasType object, not a plain Union. Stubtest compares the static type (which mypy resolves to the full Union) against the runtime object, sees they don't match, and flags it. Removing the bare import means ArrayLike is no longer a module-level name in xarray.core.variable, so stubtest never inspects it.

If this comes up again in the future (e.g. a new module imports ArrayLike or another numpy type alias directly), there are two ways to handle it:

1. Use qualified access (np.typing.ArrayLike) — prevents the name from appearing in the module namespace. This is what Update pre-commit hooks #11211 did and is the cleanest approach.
2. Add to the allowlist in _stubtest/allowlist.txt — the pattern xarray\.core\.(dataarray|dataset)\.ArrayLike$ already covers dataarray and dataset for the same reason (they import it under TYPE_CHECKING). Just extend the regex if needed.

[jsignell]

Thank you for explaining @kkollsga! That will definitely be useful knowledge in the future.