The Python Debugger

We are going to talk about the Python Debugger.

To do so, we are going to examine a piece of code that has a bug in it, and we’re going to try to hunt down that bug with the debugger.

The piece of code we are going to examine is a function called random_walker. This function simulates a random walk in two dimensions

• so you can walk in any of four directions up, down, left, or right, and each one has a 1/4 chance of occurring.

The function takes in the number of steps that you want as an argument.

For example, if you pass in 10, random_walker() will take 10 steps and prints out the location every time and return the squared distance.

The random() function that we import in from the random library generates a float from 0 and 1.

The code works by checking if the number generated is between (upper bounds excluded):

• 0.00-0.25
• 0.25-0.5
• 0.5-0.75
• or 0.75-1

Where each internal is pertaining to one of the directions left, right, up, or down.

This means each direction has a 25% chance of happening, but there is a bug in this code that we will soon discover.

We are going to run the cell random_walker(20), which will print 20 steps.

It’s hard to know immediately that something is wrong, but you can see that we’ve moved negatively in x directions (to the left) and positive in the y-direction (upwards).

If we run it again, we are going to get different outputs since it uses a random number generator random(), but weirdly, we see the same thing again.

We seem to be consistently moving left and up.

When we run it over and over, we see these results repeating.

Why do we keep moving to the left and up when this function is supposed to result in equal probability for any of the four choices.

Something seems a little bit suspicious.

What is going on?

To get help in figuring this out, we are going to use something called a breakpoint().

Breakpoint() works by stopping the executing process. Now when Python gets to this breakpoint() function (which is part of the Python debugger), the code will stop running.

We then can execute the code line by line and attempt to diagnose the problem.

We run the random_walker() function again to redefine it since we’ve added this breakpoint() function.

Now when the random_walker() function is called, it’s going to stop executing at this breakpoint.

This is what is returned.

We see this pdb which stands for python debugger.

Our code has stopped, and it shows the line Python is currently stopped on, in this case, it’sif rand < 0.25:.

If we type print(rand), we can see what the random number rand was, and it tells us 0.957.

If we type n in the debugger, it runs to the next line.

We don’t expect Python to go into the condition body, which is next in the code since rand does not meet the condition.

The next 2 lines skip the statement bodies because they are not met as well.

We do, however, meet the else condition, and so 1 is subtracted from y. Nothing seems terribly wrong yet.

Pressing n again brings us back to the top of the for loop.

We reassign rand a new random value, which turns out to be 0.0057.

Let’s go through another round of these if with our new random value.

We expect to go inside of this first if statement because the random number is actually less than a 0.25. Because our values are less than 0.25, we expect to move to the right and add 1 to x.

We run this code, and we moved to the right just like we said we would.

We keep going and check the next condition.

This is where things get suspicious.

We move to the left and to the right, which is not the intention of the code.

The intention behind this code is that only one of these four directions would be taken. If the number was between zero and a quarter, the step would be to the right. If it were between a quarter and a half, the step would be to the left, between half and three quarters, the steps would be up, and between three quarters and one, the step would be down.

This way, there is always an equal chance of each direction.

When the random number was .005, it moved in 2 directions, which doesn’t make sense since only 1 step was supposed to be taken.

Here it’s moving to the left, to the right and upward.

The reason that this happens is because the two inner if statements should be elif statements and not if statements.

In other words:

if this is the case, do this but don’t do anything else or if this is the case, do this but don’t do anything else.

By accidentally having if statements instead of elif statements, it was allowing the execution of multiple condition bodies.

Whenever a small number was generated, the movement would be left and right or just left, but it would be impossible to move right without moving left.

In general, the movement would always be left and up and not right.

So we’ve fixed the code, and we’re done with the debugger.

We stepped through the code step by step, which helped us solve the bug.

We could try and do in our head, but that can be really hard as code gets more complicated. This breakpoint is convenient because it allows us to actually see what’s happening at each step.

To get out of the debugger, we write q for “quit”.

We can remove the breakpoint() function by deleting it or commenting it out temporarily and run our cell again with the fixed code.

It’s really hard to test code that’s random since we can’t just look at the output and recognize that it’s been fixed. We can, however, run it a few times and see that steps are now being taken in different directions and things seem a little more reasonable.

The Python debugger has other functions that can help debug your code and you can explore them in the documentation.

Let’s apply what we learned!