Tue, 09 Apr 2002 20:35:55 -0400
> Tim didn't ask me before he responded; I might have suggested that
> deprecating whrandom was a bit premature given your use case.
Too late, Guido: the docs officially deprecated whrandom for the 2.1
release. The referenced thread took place long after that. Part of the
thread that wasn't referenced pointed out that random.py supplies a whseed()
method for strict bit-compatibility with whrandom.py's seed method. That
seed method sucked, though, and is inappropriate for default use. The
default Random.seed() is much better (for reasons spelled out in the docs).
> 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>.