Below is what you're missing. The author is aware of being able to specify the seed. But they want to be able to also affect library code without having to chan

Below is what you're missing. The author is aware of being able to specify the seed. But they want to be able to also affect library code without having to change it. > At this point, I should have pulled the code I was using out of that library, and refactored my game so that all sources of randomness came from some kind of pseudorandom generator function (e.g., random.Random). This way, I could provide fixed seeds for deterministic debugging. Or, a quicker method would be to use unittest.mock.patch to alter the library's random import. Instead, I thought about the different ways to alter the functionality here without making any code changes, and took a detour to catch and modify syscalls to getrandom. THAT SAID, I agree that in practice, this is an unnecessarily heavy approach. So does the author, who inexplicably ruled out run time monkey patching as "changing code" (even though it actually does not change code on the disk at all, just runtime memory data structures, and I really don't see any downside) > Or, a quicker method would be to use unittest.mock.patch to alter the library's random import. Of course the real rreason for using ptrace instead is obvious: it's more fun, it's interesting, it's a blog post topic. Nothing wrong with that! And it would work across programming languages, so is a little more general. If you had a system built up of pieces built in several languages in the same process space, this would make more sense. In practice though, the mocking or some similar runtime monkeypatching change would be simplest.