I struggled with this exercise for quite a while. I unlocked community solutions and puzzled over how simple (and brute force) some of the solutions were for generating newly initialized robot names 75,000 times without collision.
Then I noticed that they were mutating the state of the package namespace instead of an instance of the Robot struct, thereby passing state between different instances of said struct.
The exercise became trivial as a result, but I had already written a generally good cycler for my “registers” that could cycle through all possible values non-randomly until namespace exhaustion occurred.
I then removed all calls to math.rand and tested it. It still worked. As a result, I can assert that, contrary to the test description, this is not a test about randomness. This test teaches you about package-level state.
Perhaps the intent was to do this as every solution must employ this technique. If the intent is to exercise this concept, then I believe that the README should be changed to reflect this intention. If the intent is to ensure randomization, then a test should be written that can do a rough test for predicting the next value. Even a naive one that checks for a consistent difference between each iteration would do.
In either case, the proposed changes would do a better job of ensuring that the concept intended to be taught is actually taught and might even get people to a solution and gaining that knowledge more quickly, maximizing the opportunity cost of spending time on the exercise.
Additionally, the test for namespace exhaustion is a tad bit naive, as a comment even admits. A couple of lines make it more robust, and I’ve tested them myself to ensure this.
I’d be happy to submit a PR for any of these suggestions, but community contributions are closed at the moment.
Is this the right space to discuss it? Do these things seem like a non-issue? Thanks in advance for any comments and opinions!