[Python-Dev] Unittests (original) (raw)

Skip Montanaro skip@pobox.com
Wed, 10 Apr 2002 11:28:00 -0500 

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).