[Python-ideas] Raise exception if (not) true

[Andrew Barnert]

On Feb 20, 2014, at 18:23, spir <denis.spir at gmail.com> wrote:

> On 02/20/2014 10:28 PM, Steven D'Aprano wrote:
>> On Thu, Feb 20, 2014 at 09:44:57PM +0100, spir wrote:
>> 
>>> >But I would like to be able to add an error type to assertions (in addition
>>> >to the optional message). This is particularly useful for people (like me)
>>> >who systematically check func inputs (for client debugging comfort), using
>>> >assert's.
>> Then your code is systematically broken, and badly so.
> 
> Why do you speak _that_ negatively? (or should I say: _that_ violently?) And this, maybe not _that_ logically? Do you own the (copy)rights on proper usage of assert's?
> 
>> All anyone needs
>> to do to disable your checking is pass -O to the Python interpreter.
>> 
>> assert is not a short-cut for lazy programmers to avoid having to write
>> an explicit "if cond: raise SomethingAppropriate(message)". Assertions
>> have specific uses. You should read this post I made last November:
>> 
>> https://mail.python.org/pipermail/python-list/2013-November/660401.html
> 
> I think you are wrong, at least in this very case. Assert's for me are a debugging tool (or maybe more generally a tool for improving reliability). Such checks help finding errors and correcting them (thank to hopefully clear error messages), with a higher chance these corrections happen before "too late", meaning before users pay for our bugs. What else is the proper usage of assertions?
> 
> If not checked on function input, either with assert's or an if-raise combination, execution will break anyway, just later (later in time, and slightly further in code), because some input variable's value or type is wrong. Assert's placed that way are not strictly necessary (it's like duck typing: you don't need to check), instead they're a helpful tool for all users of your "service".
> 
>    def average (numbers):
>        n = len(numbers)
>        assert n != 0, "Cannot compute average of 'zero number'.", ValueError
>        return sum(numbers) / n

I think you're actually suffering from the confusion you accused Steven of. His post explains the difference between internal preconditions and external value checks. Then difference has nothing to do with the form of the function, but with how it's used.

If average is only called by your own code with your own values, so you know it can never be called with an empty list unless there's a bug somewhere, then you're asserting a precondition, which is exactly what asserts are for--but in that case this should be an AssertionError, not a ValueError.

If average is part of an external API, or is called with user data, so you're testing for something that could fail because of user error rather than a bug in your code, then this is a perfect case for a ValueError--but it's not an assertion, it's an error check.

The fact that assertions happen to work by exception handling doesn't mean you should ignore the difference between them.

> On the proposal: having a correct error type instead of "AssertionError" just helps a bit making the error report clearer for developpers.
> 
> I note in your post that, according to you, "assertions should be used for" (among other cases):
> "* checking contracts (e.g. pre-conditions and post-conditions);"
> This is precisely what I do (pre-conditions).

Checking contracts _between parts of your code_ is the paradigm case for assert. Checking contracts _between your code and your user_ is not the same thing, and you shouldn't be conflating the two.
> 
> If you don't use assert's for checking assertions which are logical truths if the code is correct, then what for?
> 
> [Side-note: I do not use here assertions for exception handling (properly speaking) at all; instead for catching errors (properly speaking). It's just that, in python and a long list of other languages, there is a complete confusion between exceptions (which belong to the app's logic, but need to be processed specially) and errors (which don't, and are our fault and our problem). Is this topic clear?]
> 
> d
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/