My sentiments almost exactly. The only 'however' I have is with respect to the 'Design By Contract' part, as I do not think of `assert` as suitable for checking the pre-condition. The way I use `assert` is that I only use it for the cases where the `assert` can not be triggered except for when other programmers circumvent the API. I use it for: * Checking loop invariants (when especially tricky). * Checking class invariants. * Checking function arguments to protected/private functions and methods. But do not use it for: * Checking function arguments for public methods. * Checking public attributes of a class. I am not sure if by 'Design by Contract' you also mean the function arguments of public functions. Ideally, when I have written a class, none of the assertions get triggered unless *I* have made a bug in the implementation of said class. In particular, bugs (or mistakes in reasoning) in other classes should not be able to trigger the assertions. To me, `AssertionError` means: The implementor of said functionality made a mistake. It should never mean: "The developer called the library incorrectly", but always: "The library is broken.". However, even though I'm also -1 on the proposal as it stands, it also makes me recognise there is something missing. To be precise: a clearly defined way of doing expensive argument checking only when no '-O' is supplied. To me, `assert foo, bar` is (really desireable sugar) for if __debug__ and not (foo): raise AssertionError(bar) And I could likewise envision wanting sugar for if __debug__ and not (foo): raise bar Where `foo` is a really expensive check (or in a tight loop!). In cases where the source is external to the library/class/function, an `AssertionError` is not the right case. def bisect(values, value): # does not make sense, as `values` comes from outside. assert is_sorted(values) # does make sense, but is 'more expensive'. if __debug__ and not is_sorted(values): raise ValueError("Expected values to be sorted") # business-logic! Now it is tempting to re-use `assert` for that, as it also has the __debug__ sugarring. But using `assert` is not correct, as `assert` is not supposed to be used for checking across boundaries. On the other hand, it might also be a cue to look into solutions for supporting pre/post-condition checking in an elegant manner. As I am writing this, it does however deem to me that it is a matter of purism vs pragmatism. What is desired is some 'checking' that is to be done only during development. So from that point, I see 3 ways forward: 1. Add new syntax for the `raise bar` case above. However, I can not really see a good name for that. Maybe `check` or `verify`, but changes are quite high that would introduce a new keyword. 2. Add support for not only strings, but also exception-subclasses as the second argument to an `assert`. 3. Do nothing. Really tempting. The first approach is most pure, but will in essence boil down to the third approach because it is most expensive. The second approach seems like an impure, pragmatic and viable approach. I may not like it, but I think it stands more of a chance than the more pure (1), and delivers more value than (3). Kind regards, Sjoerd Job On Tue, May 03, 2016 at 04:07:13AM +1000, Steven D'Aprano wrote:
On Mon, May 02, 2016 at 04:23:14PM +0200, Giampaolo Rodola' wrote:
assert statement gives the possibility to display the text which goes along with the AssertionError exception. Most of the times though, what would be more appropriate is to raise a different exception (e.g. ValueError). My proposal is to be able to specify an exception as a replacement for AssertionError as in:
assert callable(fun), ValueError("object is not a callable") ValueError: object is not a callable
My apologies for the length of this post. For the benefit of those in a hurry, here is the executive summary, or TL;DR version:
Strong -1 for this proposal.
Assertions have different semantics to explicit "if condition: raise" checks, and it is good and useful that they behave differently. In particular, a failed assert should always be a bug, and never an expected exception which the user may wish to catch. We should not blur the difference between an assert and an explict if...raise just for the sake of saving a line of code. If you find yourself wanting assert to raise a different exception type (like TypeError), that is a warning sign that you shouldn't be using assert: you're probably abusing assert for code code that needs the if...raise semantics, not the assert semantics.
Longer, and hopefully more articulate explanation (and hopefully not too rambling) follows:
I work with some people who insist on always using "assert" for all their error checking. ALL of it, whether of public or private functions, including end-user data validation. Because "it saves a line" and "it makes it easy to remember what exception to catch".[1] So their code is riddled with "try...except AssertionError", and heaven help us if the end user runs their code with -O. "It doesn't matter, nobody will do that." (Fortunately, so far the end users have not been savvy enough to know about -O.)
Assertions have a number of uses, such as checked comments, testing invariants, contract checking[2], etc. Some time ago, I wrote this to try to explain what I believe are good and bad uses of assert:
http://import-that.dreamwidth.org/676.html
I believe that assert (as opposed to an explicit test and raise) strongly communicates the intent of the programmer:
assert condition, "error"
says that this is an internal check which (in a bug-free program) is safe to disable. The assertion can be thought of as a form of "trust, but verify". There are a few different interpretations of assert, but they all agree that *assertions are safe to remove* (provided the program is bug-free). Once you are confident that the assertions will never trigger, you can safely disable them, and your program should still work.
Whereas an explicit test and raise:
if not condition: raise Exception("error")
strongly says that this is checking *external* input from a source that cannot be trusted (say, user supplied input, or external code that doesn't obey your code's internal contracts). Rather than "trust but verify" it is more "don't trust", and even in a bug-free program, you cannot do without this check. You can never disable these checks.
(By trust, I don't necessarily mean that the user or code is actively hostile and trying to subvert your function. I just mean that you cannot trust that it will provide valid input to your function. You MUST perform the check, even in a bug-free program.)
I think that the difference between those two sorts of checks is important, and I do not wish to see the distinction weakened or removed. I think that this proposal will weaken that distinction by allowing assert to raise non-AssertionError and encouraging people to treat it as a lazy shortcut for if...raise. I think it will make it harder to distinguish between program bugs and expected errors that can be caught. More on this below.
(At the risk of weakening my own argument, I acknowledge that there are grey areas where there may be legitimate difference of opinion whether a particular check is better as an assert or an if...raise. Sometimes it comes down to the programmer's opinion. But I think it is still important to keep the distinction, and not blur the two cases just for the sake of those grey areas, and especially not just to save a line and a few keystrokes.)
AssertionError strongly indicates an internal program bug (a logic error, a failed checked comment, a contract violation etc). Consequently, I should never need to catch AssertionError directly. AssertionError is always a failure of "trust, but verify" and therefore an internal bug. And importantly, no other exceptions should count as this sort of failure.
(I'm giving an ideal, of course, and in real life people vary in how rigourously they apply the ideals I describe. Some people seemingly choose exceptions arbitrarily. No doubt we all have to deal with badly chosen exceptions. But just because people will misuse exceptions no matter what we do, doesn't mean we should add syntax to make it easier to misuse them.)
For example, contract violations shouldn't raise ValueError, because then the caller might treat that contract violation (a bug) as an expected error and catch the exception. Same goes for invariants and checked comments:
process(thelist) # if we get here, the list has at least two items assert len(thelist) >= 2, 'error'
The intent here is that AssertionError is *not* part of the function API, it should not be treated as an expected error which the caller can catch and deal with. AssertionError signals strongly "don't think about catching this, it's a bug that must be fixed, not an expected error".
If the failure *is* expected, then I ought to communicate that clearly by using an explicit if...raise with a different exception:
process(thelist) # if we get here and the list has less than two items, that's an error if len(thelist) < 2, ValueError('error')
But with the proposed change, the code can send mixed messages:
assert len(thelist) >= 2, ValueError('error')
The assert says that this can be safely discarded once the program is bug-free, i.e. that the exception should never be raised. But the ValueError says that the exception is expected and the test shouldn't be removed. If ValueError does get raised, is that a failed invariant, i.e. a bug? Or an expected error that the caller can and should deal with? Who can tell? Is it safe to disable that assertion? The intention of the programmer is harder to tell, and there are more ways to get it wrong.
[1] I admit it: sometimes I'm lazy and use assert this way too. We're all human. But never in production code.
[2] As in Design By Contract.
-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/