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

[ast]

"Chris Angelico" <rosuav at gmail.com> a écrit dans le message de 
news:mailman.13.1459955565.1197.python-list at python.org...
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:
>


>> 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

thanks for these informations