> choose_boundary() ends likes so: > > timestamp = '%.3f' % time.time() > seed = `random.randint(0, 32767)` > return _prefix + '.' + timestamp + '.' + seed > > On Windows, time.time() updates fewer than 100 times per second (but more > than 10), so the timestamp format is overly optimistic about how much unique > info it can get out of time.time(). The test in question calls > choose_boundary() 100 times as fast as it can, and on Windows probably no > more than two distinct time.time() values are seen for the duration. The > chance of a boundary string duplicate is then about the chance of seeing a > duplicate from the randint() in 100 tries, which is non-trivial. > > So there are more-or-less obvious flaws in this algorithm, but I don't think > there exist any simple methods to generate a guid that's truly gu. Using a > threadsafe counter instead of randomization would at least be unique across > a program run. A simple fix would be to change the seed to use 31 instead of 15 bits; we now have a random generator capable of that. Perhaps we should go ahead and use even more bits... Aren't we using mersenne Twister by default? --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4