Just good advice? = WAS("Re: getting system date")

David Broadwell anti-spam.dbroadwell at mindspring.com
Sun May 11 17:14:02 EDT 2003


> "Terry Reedy" <tjreedy at udel.edu> wrote in message
> > and that I should be learning to avoid them?
> Of course ;-)

> If  before writing the code, he had interactively tried
> 'type(func1(*args))' to refresh his faulty memory about func1's return
> value, there never would have been a bug to ask about.
Actually i wsn't asking about the OP, or questions in general. But noting
that
types and typing seems to be a simple avoidable bug ridden hole in the
groud,
was asking what the other way oround generally is.

> One can also use the manual (which I also do), but actual evidence is
> more definitive and possibly faster.  Even when I am writing in an
> editor, I sometimes use an interactive window for quick answers about
> actual behavior.
*lol* i honestly doubt i'd code half as well without a interactive test bed
that i can beat on. In this case the interpreter.

>From what you hinted at, i'll leave in my 'paranioa' tests in many of my
routines that test things that the computer will never make a mistake on,
but that i might.

def zoobar(somelist):
    ''' Takes a list an complains if it dosen't like it, might even give it
back '''
    if somelist:
        if type(somelist) == type([]): # paranoia type tests ... bad coder,
no biscut.
            print "good list, put code here"
            return somelist
        else: print "zoobar requires list types not %s" % type(somelist)
    else: print "zoobar need argument ... a list would be good."

So, question is; in the long run, are these kind of tests worth it?
And; what kind are the best 'parnaoia' tests to do?






More information about the Python-list mailing list