Python input validity and using asserts

Question

I'm trying to perform good input validity checking on my python code, but I also want it to be succinct. That is, the solution I don't want to go with is this one:

def some_func(int_arg, str_arg, other_arg):
    try:
        int_arg = int(int_arg)
    except TypeError, ValueError
        logging.error("int_arg must respond to int()")
        raise TypeError
    try:
        if str_arg is not None:
            str_arg = str(str_arg) 
    except TypeError
        logging.error("Okay, I'm pretty sure this isn't possible, bad example")
        raise TypeError
    if other_arg not in (VALUE1, VALUE2, VALUE3):
        logging.error("other arg must be VALUE1, VALUE2, or VALUE3")
        raise TypeError

This is just too much code and to much space to spend on just checking 3 arguments.

My current approach is this:

def some_func(int_arg, str_arg, other_arg):
    try:
        int_arg = int(int_arg)  #int_arg must be an integer
        str_arg is None or str_arg = str(str_arg)  #str_arg is optional, but must be a string if provided
        assert other_arg in (VALUE1, VALUE2, VALUE3)
    catch TypeError, ValueError, AssertionError:
        logging.error("Bad arguments given to some_func")
        throw TypeError

I lose the specificity of my log message, but this is much more succinct and honestly more readable in my opinion.

One thing specifically I'm wondering about is the use of the assert statement. I've read that it's discouraged to use assertions as a way of checking input-validity, but I was wondering if this was a legitimate way to use it.
If not, is there a similar way to perform this check (or do this validation in general) that's still pretty succinct?

Answer 1

You could invent a decorator that would validate the arguments for you.

This is how the syntax could look like:

@validate(0, int)
@validate(1, str, logMessage='second argument must respond to str()')
@validate(2, customValidationFunction)
def some_func(int_arg, str_arg, other_arg):
    # the control gets here only after args are validated correctly
    return int_arg * str_arg

---

This is a naive implementation of the validation decorator factory.

def validate(narg, conv, logMessage = None):
    def decorate(func):
        def funcDecorated(*args):
            newArgs = list(args)
            try:
                newArgs[narg] = conv(newArgs[narg])
            except Exception, e:
                # wrong argument! do some logging here and re-raise
                raise Exception("Invalid argument #{}: {}".format(narg, e))
            else:
                return func(*newArgs)

        return funcDecorated
    return decorate

Yes, there's a bit of function nesting here, but it all makes sense. Let me explain:

• A decorator is something that takes one function and returns another
• We want validate(narg, converter) to be a function that takes some settings and returns a specific decorator (decorate) which behaves according to these settings
• decorate is then used to decorate a given function (func) that takes some positional arguments by creating a new function funcDecorated that takes the same arguments as func (*args) and is written in terms of input function func as well as the initial settings narg, conv.

The actual validation happens inside funcDecorated, which...

• takes the input argument list,
• replaces n-th argument by validating and/or converting it (whatever conv does),
• calls the input func with the altered argument list.

To do this for several arguments, we apply validate multiple times with different arguments. (It's possible to rewrite it to only decorate once, but it looks more clear this way IMO.)

See it in action: http://ideone.com/vjgIS

---

Note that conv can act either...

• as a validation function (return whatever it receives, but throw if it's invalid)
• as a conversion function (return the converted value, throw if can't convert)

Note that this implementation doesn't handle keyword arguments.

Answer 2

Using assertions is perfectly fine for checking arguments validity (type, class or value, that are precisely the things you are checking).

You said:

One thing specifically I'm wondering about is the use of the assert statement.

So I think this page can be useful to you.

In particular this part:

Assertions should not be used to test for failure cases that can occur because of bad user input or operating system/environment failures, such as a file not being found.