[Python-Dev] Unittests

[Skip Montanaro]

    mal> Why not have both whrandom and random around ? ... with whrandom
    mal> using the tools from random ?

If I understood Tim correctly yesterday, whrandom's seed method was pretty
bad.  Migrating the whrandom algorithms to the random module made sense, and
having a seed method made sense, but it had to be an improved seed method.
If you're going to create a semantically different seed method, you might as
well deprecate whrandom altogether.  Allowing people to continue using
whrandom with the old seed method gives them a false sense of security that
they have a good random number generator at their disposal.  Using it with a
new and improved seed method may allow their code to break in subtle ways.
To make matters worse, most people don't even realize they are calling seed
in the first place.  The best course is simply to deprecate whrandom so
people have to explicitly address the issue.  Explicit is better than
implicit.

That said, when I mapped "whrandom" to "random" in my own code, I completely
ignored this issue with no problems.  Of course, my use of random numbers is
not all that demanding.  When I multi-threaded my XML-RPC server I had to
address locking issues though.  Most people will probably be able to execute

    s/whrandom/random/g

and be done with it.  Those people who aren't able to make that simple
translation are probably rare and know what the issues are.

    mal> I don't see the value of deprecating a stone-old module
    mal> just because there's a new flashy module with a different
    mal> name around. If it's possible to maintain backward
    mal> compatibility then it should be maintained. Period.

It's not just a different name.  It's subtly different semantics.

Skip

P.S.  I Trust Tim (tm).