> > I can certainly see the use of providing a given random algorithm for > > those who want stability, while at the same time letting the random > > module migrate to a stronger algorithm for the benefit for humanity. > > > > But then again, Tim might have a good reason why that's a bad idea. I > > don't know. > > It's a good idea, but what was a bad idea was continuing to call the > bad seed method plain "seed()". I toyed with adding a "version > number" argument to seed, and that may still be a good idea; the > random.py getstate() does *save* a version number, so that it's > possible to change default methods entirely someday yet unpickle old > random instances (2.1 or later) and get back the same generator you > thought you had pickled. I ran out of time before I ran out of > ideas, though <wink>. I'll leave it to the OP to continue this thread. --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