Checking function's parameters (type, value) or not ?

Chris Angelico rosuav at gmail.com
Wed Apr 6 11:12:36 EDT 2016


On Thu, Apr 7, 2016 at 12:18 AM, ast <nomail at com.invalid> wrote:
> "Mark Lawrence" <breamoreboy at yahoo.co.uk> a écrit dans le message de
> news:mailman.131.1459949361.32530.python-list at python.org...
>>
>> On 06/04/2016 14:07, ast wrote:
>
>
>>
>> Please see
>> http://ftp.dev411.com/t/python/python-list/13bhcknhan/when-to-use-assert
>>
>
>
> Thanks for this paper
>
> Running Python with the -O or -OO optimization flags
> removes the assert. This has to be known.

Exactly. So your two options are not "remove the assertions" and "keep
the assertions"; they are "remove the assertions" and "replace the
assertions with explicit exception raising". My recommendation is
still on simply removing them, but if you are to keep the checks,
they'll look something like this:

def to_base(nber, base=16, use_af=True, sep=''):
    """docstring goes here (don't forget that)"""
    nber = int(nber)
    if nber < 0: raise ValueError("Negative numbers not supported")
    base = int(base)
    if base < 2: raise ValueError("base must be at least 2")
    use_af = bool(use_af)
    sep = str(sep)


These are either conversions or assertions, depending on your point of
view. Actually, it would be better for these to have some kind of
"ensure that this is X" call; you could replace int(x) with
operator.index(x), but there's no equivalent for str - any object can
be converted to a string. You could perhaps do that one with
isinstance. (IMO bool is fine as it is.)

But I would just leave out this code altogether. Less code means less
chance of bugs creeping in; you might change the code elsewhere to
require, for instance, that base not exceed 36, and then you'd have to
come and change this code too. Without the checks, you'd only make
that change in one place.

ChrisA



More information about the Python-list mailing list