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