I have questions about thread safety in the 'random' module. When using the random.Random class (be it Mersenne Twister or Wichmann-Hill based), is it sufficiently thread-safe (preserving entropy and guarding against attack) to just have each thread work with its own random.Random instance? Or do I need to wrap my calls to each instance's methods to use locks? Wichmann-Hill in particular has the warning in its .random() vulnerability; do I need to make an exception for that case?
What about when using the random.SystemRandom class (be it based on /dev/urandom or CryptGenRandom based)? Should I be doing anything in my code to ensure that /dev/urandom, for example, is polled serially? (I thought I read somewhere that this was advisable). SystemRandom claims it has no state, which may be true at the Python class level, but is that guaranteed to be true for the underlying RNG? Also, side note: The doc string for random.SystemRandom says "Not available on all systems (see os.urandom() for details)" ...but os.urandom()'s doc string provides no details. Actually, os.urandom() and random.SystemRandom are "available" on all systems (they exist and can be called/instantiated), but os.urandom() can raise a NotImplementedError (any time it is called, in theory), therefore random.SystemRandom's methods can fail with a bubbled-up NotImplementedError (on non-win32 OSes, at least). At the very least, this should be documented. I'm not in a position to submit a patch, but will submit a documentation bug report if so advised. Thanks, Mike -- http://mail.python.org/mailman/listinfo/python-list