Thanks! Would be good to have a couple of tests for this behaviour to make sure it doesn't regress again!

I've added a simple test. Honestly unsure how to add any more but I think this should suffice.

So as I was using this in some other code and I discovered that it's actually incorrect for an edge case.
Specifically if range outputs a whole number then you still get uneven distributions.
An example being a length 50 array split over 4 gives 13,12,13,12.

I have a solution, it's a bit inelegant as it uses a for loop, but it should be strictly correct since we are no longer relying on rounding based on range output.

This is my first time in this situation so I'm not sure what the best way to push the fix is.

You will need to open another PR. So checkout current master locally and branch of there, add your fix + test and open a new PR for that.

Ah I see you worked on master for this PR.
So do something like this:

git fetch
git checkout origin/master
git checkout -b jt/myfix
# Then do your fix
git push -u yourremote jt/myfix

and open a new PR. You can also do git checkout master; git reset --hard origin/master to get back in sync with upstream, but that will lose you changes you might have made.