[Python-Dev] Unittests

[M.-A. Lemburg]

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/