For me, correctness seems equally easy to see. The loop invariant is that x[:i] is shuffled. A new element is mixed in at every step. It's just an insertion-shuffle vs a selection shuffle. The reverseless code is a bit easier because reasoning about reverse loops is more awkward than for forward loops. I hear what you're saying about changing existing seeded shuffles. That is my only misgiving. Thanks for looking at this.

Yes, both ways fold in a new item on each iteration - but only the backwards way also removes an item from consideration on each iteration. In the standard way, after the first iteration each item has an equal chance of being swapped into the final position, and that's obvious, and it's thereafter impossible for the final position to change value again. That's what makes it very obvious - you can forget about it, it's done. Each iteration determines the final value at one position.

Go forward instead, and no position is eliminated as iterations go on. Even on the last iteration, you still can't know coming in what the final value of any position will be - you can only state an invariant involving all positions. Try writing formal proofs, and I bet you too will find that harder to account for.

Would it be faster to replace reversed(range(1, len(x))) by range(len(x)-1, 0, -1)?

Would it be faster to replace reversed(range(1, len(x))) by range(len(x)-1, 0, -1)?

Under PyPy, almost certainly. But I happen to know that Raymond has an aversion to range() with a negative step so strong that it wasn't worth mentioning 😉.

It so happens I prefer the reversed() spelling too, but then "speed" means nothing to me here - the cost of iteration in this context is bound to be insignificant compared to the cost of calling _randbelow() on each iteration, even under PyPy.