assert is a weak debugging tool
Here's something (perhaps obvious) that recent experience has taught me:
assertis a pretty bad debugging tool.
The problem is that a failed
assert gives you almost no information,
just that it did fail. Almost all the time, you need to know something
about what the bad values are in order to actually debug the problem,
so your first step is to transform '
assert condition' into something
if not condition: print <stuff> assert condition
(The exception that proves the rule are assertions added just to see if a particular condition was as impossible as you thought; there, once you know it's not impossible you're going to be adding code to handle it properly.)
One quick fix is to start using the two-expression form of
which at least lets you bundle a useful message (complete, hopefully,
with some state information) with the assertion failure. But it's
difficult to predict in advance just what information you're going
to need to debug something that you thought was impossible when you
wrote the code.
(Writing these entries is educational, as it forces me to actually do
careful research so that I don't write something truly stupid instead of
just relying on my memories. In other words, I didn't know that
could also be given a message to assert with until just now.)
I consider this especially annoying in
assert's case because it is a
part of the language. As a language builtin, it could break the normal
rules constraining functions in order to be more useful and do clever
things like print information about the variables involved in the
It's possible to do your own version of
assert, or to use a traceback
hook in order to make it smarter; possible things to do include dumping
local variables and entering the debugger. So far I haven't tried to
build anything like this myself, although the automatic variable dumping
code would make an interesting exercise in playing around with deep
Comments on this page:Written on 29 October 2006.