Thank you! As this is a new feature that adds to our API surface, we do ask that you discuss this on the mailing list first. In the issue that you linked, I don't think any numpy maintainer actually participated in the discussion.

We are quite conservative in which functions that we add to the main numpy namespace. We like to coordinate with the Array API Standard especially since there are other similar implementations around like Pandas'. You might do better to propose an addition to the Array API, which will get the attention and input from other array implementors as well.

@rkern Done.

You might do better to propose an addition to the Array API

They've previously asked me to post here instead. 🙂 Seems like a catch-22.

@jorenham Done. So many places to keep track of. 😅 I wonder if that could be improved. (Cutting down the number of places that each function needs to be declared in, reducing the size of the codebase and making it easier to edit.)

So many places to keep track of. 😅 I wonder if that could be improved. (Cutting down the number of places that each function needs to be declared in, reducing the size of the codebase and making it easier to edit.)

I spend most of my time writing stubs, so I've given up on my DRY dreams haha.

But there are some tools that usually help spot these kind of errors, e.g. ruff complaining about unused imports, or stubtest reporting that the __all__ in the stubs does not match the runtime one. Getting the codebase to the point where we'll be able to use those tools is quite a lot of effort though...

I think in principle having the option to shift rather than roll is nice to have, and fairly frequently used. I wonder, though, if a standalone function is the best way forward. Two alternatives,

• Add a fill_value keyword argument to roll, with the default of None (or maybe np._NoValue) meaning to roll.
• The functionality is fairly trivial to implement using np.pad -- with the input shortened along the correct axis -- so the function would just be a wrapper around it (indeed, roll could similarly be a wrapper, but I think that was defined before pad had the relevant options). The advantage is that this gives additional options of what to do with the fill value.

Note that even if we don't go with either of the above, we should not have so much code duplication between np.roll and np.shift!

p.s. If we do go with a new function (not sure we should!), I'd prefer to just call it np.shift, i.e., imply an action, just like np.roll and np.pad.

@mhvk

Thanks for your comments.

(or maybe np._NoValue)

I disagree with this bit specifically. I think users should be able to set a behavior by changing a value, not just by omitting it.

The functionality is fairly trivial to implement using np.pad -- with the input shortened along the correct axis

That would take up extra memory, especially when shift is large. That might be undesirable, I think.

I'd prefer to just call it np.shift, i.e., imply an action, just like np.roll and np.pad.

I also prefer np.shift in principle, but it conflicts with the shift argument, and I call the function inside itself to handle the axis=None case.

I could rename the shift argument to amount or something else.

Also open to other suggestions.

Why would it take more memory? You're creating a new array here too, and passing a shortened view to np.pad does not cost any extra memory.

Nevermind. I see what you meant.