Proposal: runtime validation statement

Paul Rubin http
Sun Jul 11 17:12:34 EDT 2004


I frequently find myself writing stuff like

    # compute frob function, x has to be nonnegative
    x = read_input_data()
    assert x >= 0, x               # mis-use of "assert" statement
    frob = sqrt(x) + x/2. + 3.

This is not really correct because the assert statement is supposed to
validate the logical consistency of the program itself, not the input
data.  So, for example, when you compile with optimization on, assert
statements become no-ops.  And yet, it's generally desirable to
validate input whenever you can, and raising an exception is
frequently the right thing to do with bad data.  A function like

    class ValidationError(Exception): pass
    def _validate(cond, message):
       if not cond: raise ValidationError, message

takes care of it, of course, so it's slightly redundant to add a
special statement like

    validate x >= 0, (x, "must not be negative")

which works exactly like assert but raises a different exception and
is never optimized away.  But the same can be said of the print
statement (use sys.stdout.write or a print function instead) and for
that matter the addition operator (use "x - (-y)" instead of x+y), the
bool type (use 1 and 0 instead of True and False), etc.

We have to conclude that choosing what statements the language
supports is not just a matter of making things possible, but also of
steering what the common idioms should be.  Using a user-defined
function to check input means a couple more program-specific things to
remember (the function itself and the exception class it raises),
clutters up the code, etc.  And so I've come to feel that a "validate"
statement (maybe with some different keyword) like the above is in the
Pythonic spirit and should be considered for some forthcoming release.

Thoughts?



More information about the Python-list mailing list