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

M.-A. Lemburg mal@lemburg.com
Wed, 10 Apr 2002 19:48:27 +0200

Skip Montanaro wrote:

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.

There's nothing bad in the .seed() method. You just have to pass it some sane values (rather than relying on the defaults).

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.

You won't have much luck in doing s/whrandom/random/g on a hard-copy Python text book and this is what Python newbies read. I'm not even talking about potential Python users who haven't gotten the slightest idea what sed is... :-)

Note that the key point is a different one: every single deprecation causes work (convincing management, code changes, tests, deployment of the new code, training application developers, writing/buying new books). Work costs money. Money causes all sorts of problems.

If not absolutely needed in order to make way for new techniques or features, we should leave the old established code in place rather than causing endless support sessions with customers who fear that the code you've written for them 6 months ago starts making not so funny noises or that drag you to update the code on a warranty basis.

What's worse, is that management will not be delighted to see that this "new technology we use, called Python" causes quality assurance and training costs every 8-12 months. I wouldn't want Python to go down that road, now that the ball is starting to roll.

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.

It should be no problem emulating the old behaviour using the new code or simply leaving the old code in place (it's not broken in any way).

Marc-Andre Lemburg CEO eGenix.com Software GmbH

Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/