I argued against step_size when we designed this function, because you can get that behavior
already with sliding_window_view(x, 3)[::2].

Yes, I would also like to see sliding_window_view more exposed. This probably means putting a stub in numpy/lib/__init__.pyi and including it in the __all__ of numpy/lib/stride_tricks.py. I'm not sure if any of these files are automatically generated, but I've added them manually in my own numpy. I would be willing to make a PR of this quick fix. (I'm not sure if the more dangerous as_strided should be exposed.)

My use case also needs a step size, but as @eric-wieser suggested, I have achieved that with slicing. This shouldn't be more expensive, since the result is a view on the array already.

Shall I make a PR for this?

Edit: And if so, should it be exposed in numpy or numpy.lib?

Note that this was deliberately moved out of the main namespace in #17720, in response to a comment by @rgommers that I can't find any more. on the mailing list:

The old PR had this in the lib.stride_tricks namespace. Seeing it in the main namespace is unexpected and likely will lead to issues/questions, given that such an overlapping view is going to do behave in ways the average user will be surprised by. It may also lead to requests for other array/tensor libraries to implement this. I don't see any discussion on this in PR 17394, it looks like a decision by the PR author that no one commented on - reconsider that?

and further down the same thread:

Other issues include:
2) It is very specific to NumPy's memory model (as pointed out by you and Sebastian) - just like the rest of stride_tricks
3) It has "view" in the name, which doesn't quite make sense for the main namespace (also connected to point 2 above).
4) The cost of putting something in the main namespace for other array/tensor libraries is large. Maybe other libraries, e.g. CuPy, Dask, TensorFlow, PyTorch, JAX, MXNet, aim to reimplement part or all of the main NumPy namespace as well as possible. This would trigger discussions and likely many person-weeks of work for others.
5) It's a useful function, but it's very much on the margins of NumPy's scope. It could easily have gone into, for example, scipy.signal. At this point the bar for functions going into the main namespace should be (and is) high.

All this taken together means it's not even a toss-up for me. If it were just one or two of these points, maybe. But given all the above, I'm pretty confident saying "it does not belong in the main namespace".

Ah apologies in that case, I didn't know that. No plans to completely remove this feature hopefully 😅 ?

Yes, I would also like to see sliding_window_view more exposed. This probably means putting a stub in numpy/lib/__init__.pyi and including it in the __all__ of numpy/lib/stride_tricks.py.

A reorganization of the numpy.lib namespace is in the works to make that namespace more useful and discoverable, see gh-18447 and https://mail.python.org/pipermail/numpy-discussion/2021-February/081527.html. That should help.

No plans to completely remove this feature hopefully 😅 ?

No, we just added it in the most recent release.

Hi @rgommers, I’m curious to know if there has been any development regarding the mentioned reorganization?

I find myself keep going back to how to implement a sliding window properly, and numpy’s seems to mostly satisfy my needs, I say mostly since it’s location is annoying to remember and the function name is too long, if possible I would suggest renaming it to ‘window’.

Hi @rgommers, I’m curious to know if there has been any development regarding the mentioned reorganization?

gh-18447 made some initial steps, but it seems to have stalled.

if possible I would suggest renaming it to window.

That's way too generic a name; even in numpy itself we have other "window functions" like bartlett, hanning, etc.