Tue, 21 Nov 2000 22:12:44 -0500
> As a user, I don't expect much argument verification from the Python
> library at all! C-level verification makes sense because the alternative
> is core dumps. That's not acceptable.
Why not? I don't see any real difference between a core dump and an
uncaught & unexpected Python exception: in either case the program didn't
get the job done, and left stuff in an unknown state. Nothing
supernaturally evil about a core dump in that respect; if one is
unacceptable, so is the other. In the good old days a core dump often
crashed the OS too, but that's rare even on Windows now.
> For the rare Python-coded function that DOES do argument verification, I
> wouldn't have much of an expectation of the affect of "-O" on it
> because, like Jeremy, I hardly ever use -O. So maybe the argument is not
> worth having -- if nobody ever uses -O then we should always just
> balance safety and performance rather than expecting the user to choose
> one or the other.
I don't care about argument verification except to the extent that it
validates preconditions. If the preconditions for using a public function
aren't stated, the docs are inadequate (what's the user supposed to do then?
guess?). If the preconditions aren't verified, then a user error may lead
to an incomprehensible error somewhere in the bowels. Most library
functions have preconditions of the form "x is a sequence" or "y supports
.sort()", and for such builtin types & operations laziness is usually
tolerable because the specific exception raised by accident (in the absence
of checking and the presence of a bad argument) says "not a sequence" or
"can't be .sort()ed" more or less directly. If you've got fancier
preconditions, an accidental exception likely makes no sense at all to the
Andrew's claim was "some simple parameter checking, though, shouldn't add
too much of a burden, and will protect users from common mistakes that will
result in invalid trees". I'm arguing both that validation is valuable to
the user and that "-O" is a rotten way to turn it off (even if people *did*
use it -- and I agree that few ever do). Without any validation first,
though, an argument about how to turn it off-- or whether there's even a
need to --is at best premature. If Andrew is wrong (that user mistakes
aren't common, or that simple checking couldn't protect users in a useful
way), I haven't heard anyone say so.
if-not-the-rest-is-just-a-question-of-biting-the-bullet-ly y'rs - tim