Thanks to visit codestin.com
Credit goes to github.com

Skip to content

TYP: np.lib.stride_tricks.sliding_window_view parameter axis typing is inconsistent with documentation and implementation. #31233

@pfournier01

Description

@pfournier01

Describe the issue:

In the stub file numpy/lib/_stride_tricks_impl.pyi, the definition of sliding_window_view states that the axis parameter is an optional SupportsIndex (so a single axis).
In the documentation, and in the implementation, it accepts a numpy._typing._ShapeLike.

Type stubs:

@overload
def sliding_window_view[ScalarT: np.generic](
x: _ArrayLike[ScalarT],
window_shape: int | Iterable[int],
axis: SupportsIndex | None = None,
*,
subok: bool = False,
writeable: bool = False,
) -> NDArray[ScalarT]: ...
@overload
def sliding_window_view(
x: ArrayLike,
window_shape: int | Iterable[int],
axis: SupportsIndex | None = None,
*,
subok: bool = False,
writeable: bool = False,
) -> NDArray[Any]: ...

Documentation:

Parameters
----------
x : array_like
Array to create the sliding window view from.
window_shape : int or tuple of int
Size of window over each axis that takes part in the sliding window.
If `axis` is not present, must have same length as the number of input
array dimensions. Single integers `i` are treated as if they were the
tuple `(i,)`.
axis : int or tuple of int, optional
Axis or axes along which the sliding window is applied.
By default, the sliding window is applied to all axes and
`window_shape[i]` will refer to axis `i` of `x`.
If `axis` is given as a `tuple of int`, `window_shape[i]` will refer to
the axis `axis[i]` of `x`.
Single integers `i` are treated as if they were the tuple `(i,)`.
subok : bool, optional
If True, sub-classes will be passed-through, otherwise the returned
array will be forced to be a base-class array (default).
writeable : bool, optional
When true, allow writing to the returned view. The default is false,
as this should be used with caution: the returned view contains the
same memory location multiple times, so writing to one location will
cause others to change.

Implementation:

if axis is None:
axis = tuple(range(x.ndim))
if len(window_shape) != len(axis):
raise ValueError(f'Since axis is `None`, must provide '
f'window_shape for all dimensions of `x`; '
f'got {len(window_shape)} window_shape elements '
f'and `x.ndim` is {x.ndim}.')
else:
axis = normalize_axis_tuple(axis, x.ndim, allow_duplicate=True)
if len(window_shape) != len(axis):
raise ValueError(f'Must provide matching length window_shape and '
f'axis; got {len(window_shape)} window_shape '
f'elements and {len(axis)} axes elements.')

Reproducibility:
I created a fresh environment:

mkdir numpy_typing
cd numpy_typing
uv init
uv add numpy
uv add mypy

Note: I'm very willing to send a PR to fix this but since it´d be my first contribution to numpy, I wouldn't mind being a bit guided on the process.

Reproduce the code example:

import numpy as np

x = np.zeros((10, 20, 20))
window_shape = (5,5)
axis = (1,2)
np.lib.stride_tricks.sliding_window_view(x=x, window_shape=window_shape, axis=axis)

Error message:

main.py:6: error: No overload variant of "sliding_window_view" matches argument types "ndarray[tuple[int,
 int, int], dtype[float64]]", "tuple[int, int]", "tuple[int, int]"  [call-overload]
main.py:6: note: Possible overload variants:
main.py:6: note:     def [_ScalarT: generic[Any]] sliding_window_view(x: _SupportsArray[dtype[_ScalarT]] 
| _NestedSequence[_SupportsArray[dtype[_ScalarT]]], window_shape: int | Iterable[int], axis: SupportsInde
x | None = ..., *, subok: bool = ..., writeable: bool = ...) -> ndarray[tuple[Any, ...], dtype[_ScalarT]]
main.py:6: note:     def sliding_window_view(x: Buffer | _SupportsArray[dtype[Any]] | _NestedSequence[_Su
pportsArray[dtype[Any]]] | complex | bytes | str | _NestedSequence[complex | bytes | str], window_shape: 
int | Iterable[int], axis: SupportsIndex | None = ..., *, subok: bool = ..., writeable: bool = ...) -> nd
array[tuple[Any, ...], dtype[Any]]
Found 1 error in 1 file (checked 1 source file)

Python and NumPy Versions:

Numpy version: 2.4.4
Python version: 3.14.3 (main, Feb 13 2026, 15:31:44) [GCC 15.2.1 20260209]

Type-checker version and settings:

Type checker used: mypy 1.20.1 (compiled: yes)
Mypy used with default configurarion on new installation.

Additional typing packages.

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions