The alternative I was considering was _axis_slice(arr.shape, lambda n: slice(n-1, n), axis=axis), which covers a few more uses, but I wasn't sure if that was clearer.

Not clearer as written, but I think it would be clearer if one were to just pass in the required slice itself. This is possible, since, as I noted above, it is not necessary to know the actual dimension; here, one would just pass in slice(-1, None).

One doesn't actually need the shape for either _begin_slice (obvious, it is not used), or _end_slice: just do

def _end_slice(ndim, n, axis):
    return tuple(slice(None) if i != axis else slice(-n, None) for i in range(ndim))

-n fails when n == 0. I'd like to remove some of the zero special-casing, if possible

Actually, thinking more, we do not need ndim either, since you only need a tuple up to axis - all the later dimensions are automatically taken to be slice(None). So, it could be:

def _slice_at_axis(axis, slice):
    return (slice(None),) * axis + (slice,)

(This is substantially faster than the loop, at least for a randomly selected axis=3.)

Perhaps pass in slice(arr.shape[axis] - padding, None) in that case - at least it is immediately obvious what the code does.

I was trying to avoid writing axis twice, hence the lambda function above.

This is substantially faster than the loop

I suspect this would be true if I kept my existing function names but changed their implementations too (I deliberately didn't do that in this PR, because it makes the diff clearer)

Yes, the last half is redundant - but it produces the same slices as we did before, and I see little reason to change that.

Note that this slice is the reverse of what it was before - but min, max, mean, and med all are order-invariant anyway