Here's something (perhaps obvious) that recent experience has taught me:

Python's assert is 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 like:

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 assert, 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 assert 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 failing expression.

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 Python introspection.