from Hacker News

When to use assert

by martinvol on 11/17/13, 6:26 PM with 41 comments

by mickeyp on 11/17/13, 8:22 PM
The most important thing to remember with assertions vis-a-vis optimising compilers removing assertion calls: you should never have assertions that cause side effects.
Bad:
assert InitialiseStuff() != False, 'Initialise failed'
If the optimising compiler is set to eliminiate assertions the InitialiseStuff function won't get called! This will (subtly, or not so subtly) break your program!
by mrmaddog on 11/18/13, 5:35 AM
Once you do decide to use an assert in python, there are a couple things to consider. The first is to make sure you are expressive in your message. Your assert may very well hit one day, and it may only occur at the most unpredictable times, so you'll want to make sure you have enough information to see why the assert failed. To use the OP's example:
```
  assert x > 0, "x is not zero or negative"
```
When this fails, you're going to be at a loss to understand what actually happened. If you change the message to something like the following, you're going to have a much easier time tracing through your program to understand why your constraint was violated:
```
  assert x > 0, "Expected positive x, got: %d" % x
```
Once you get in the habbit of this, you'll quickly run up against style-guide imposed line limits. My usual trick here is to use parenthesis and let python's automatic string concatenation work its wonders, but you have to be careful because
```
   assert (x > 0, "This is my longer message "
           "for x")
```
evaluates to a tuple, and thus is always true. Instead only use parens around the message:
```
   assert x > 0, ("This is my longer message "
                  "for x")
```
Lastly, don't use asserts in tests. Use the standard unittest library which will do a much better job explaining what was received, what was expected, and what the difference between them is.
by ggchappell on 11/18/13, 1:47 AM
Well, I have to agree with the general point here, but it's buried inside a mass of wandering prose, and I'm not even sure the author quite gets it.
Here is (IMHO) the point: assert is for checking invariants.
That said, I doubt that a post like this is a good place to teach people what invariants are. Those who don't know should go learn. To some small extent, that might include the author, as, for example, pre- and post-conditions are not some special contract-thing that is separate from invariants; they are special kinds of invariants. (So, yes, use assert to check contracts; that's part of checking invariants)
And:
> You wouldn't write code like this:
```
  if not isinstance(x, int):
      raise AssertionError("not an int")
```
Sure I would, if x being an instance of int is an invariant of my code. But if it isn't, then I wouldn't.
I also accept that, as the author says, "assert" has its quick-and-dirty uses. Putting an "assert False" around an unwritten portion of code is a reasonable thing to do, particularly if it is code that one expects to be used often, as the "assert" will continually complain of its own existence as long as it is there.
by shin_lao on 11/17/13, 8:55 PM
Assertions are also a great way to say: "this should be true, if this is not true, the code behavior is undefined."
Carefully using assertions is a great way to see if you are building your code wrong. Like a way to tell you "you're trying to fit the wrong lego piece in".
by ak217 on 11/18/13, 5:14 AM
I was frustrated with the limited utility and expressiveness of Python assertions, so I wrote a library for expressive assertions:
https://github.com/kislyuk/ensure
It's inspired by ensure.js, and defines a large (and growing) number of helpers to make assertions concise, easy to read, customizable, and more usable than the assert statement. (Feedback welcome!)
by ForHackernews on 11/17/13, 7:24 PM
Seems like this was written by Steven D'Aprano, not Guido.
by deckiedan on 11/18/13, 7:35 AM
You can do type-class tricks with it if you want...
```
    class Username(unicode): pass
    class Directory(unicode): pass

    def updateUserHomeDir(name, dirname):
        assert isinstance(name, Username)
        assert isinstance(dirname, Directory)

        update_etc_passwd(name=name, dirname=dirname)
```
or whatever. This only really starts to become useful when you start adding sanity checks into the classes:
```
    class Directory(unicode):
        def __init__(*vargs, **kwargs):
            super(Directory, self).__init__(*vargs, **kwargs)
            if not os.path.is_dir(self):
                if not os.path.exists(self):
                    make_dirs(self)
```
just a bit cleverer in reality. You then move all the directory-path sanity checks into there. You can also subclass further for `class ValidHomeDir(Directory)`, etc.
The benefit of this is that you don't have to run your sanity checks more than once, you can pass the values around as much as you need and be sure that they have been initiated correctly. Use of your functions becomes at worst:
```
    updateUserHomeDir(Username('dan'), Directory('/home/daniel'))
```
which isn't so bad, really.
And it's fine to be optimised out, as the code paths are what are being checked here, not the user data. :-)
I don't know how "pythonic" the idea is, but it does seem reasonably elegant to me, and solves some of the problems of python's otherwise fun duck-typing.
by euphemize on 11/17/13, 8:26 PM
This is really useful. I've been coding python projects for a few years now and was never quite sure how/when to use them. You'd run into assert when unit testing, but not that much elsewhere. This makes it clearer, I like this quote : Don't use assert for checking anything that you expect might fail in the ordinary use of your program. Assertions are for extraordinary failure conditions.
by penguindev on 11/17/13, 8:49 PM
"Assert is not a shortcut for lazy coders."
Then they need to make something better for me. My c and python code isn't functional with asserts compiled out, because assert just makes my life easier.
In a perfect world, current assert semantics would be _DEBUG_ASSERT (all caps to let you know it has macro-ish behavior), and the normal assert would always be on.
by gcb1 on 11/17/13, 10:01 PM
his example of design by contract is silly out of functional testing. why would i even contact an external service/api if my own code can know what it will get back every time? other than a side effect service, such as calling a disk IO and checking that return code means success, but then my check does not check anything...
by CraigJPerry on 11/17/13, 8:05 PM
I look at asserts as twitter for comments.
by jheriko on 11/17/13, 8:14 PM
this is a fascinating piece of advice - there is no argument against heavy use of assertions i have heard which isn't "oh but i'm lazy and don't want to do my job properly" and whilst that is e.g. the justification for python as a language in the first place that we don't want to spend time writing bytes, its not about convenience in this case but necessity. writing everything at the lowest level is not necessary, but writing stable code is. assertions help you do this, they will not become obsolete until e.g. static code analysis becomes good enough to replace it.
this comment is also scary from the C family of languages background:
"When using assert properly, this is a feature, but when assert is used inappropriately, it leads to code that is completely broken when running with the -O flag."
why don't people test their software by merely running it? esp in the config it will ship in.
by IgorPartola on 11/18/13, 1:33 AM
Wouldn't the example with the if/elif be the same as the above TypeError one? I suppose a ValueError would actually be more appropriate.
Proper design by contract support would be great too.