CptS 481 - Python Software Construction

Unit 13: Checking and Debugging

pylint

pylint takes a "picky" approach to code analysis. The "lint" part of the name comes from an early C program checker.

We start with the same "0_sloppy.py" file:

So if we clean this up a bit...

Let's try a more useful program: "3_polar_for_sphinx.py".

pdb

Here's a little program, "4_faro_py2k.py" written in Python 2K.

Run with Python2K, it runs fine:

But in Python3K, there are problems. (If you're running this in your own IPython Notebook, session, you may need to interrupt the kernel.)

So one thing we clearly have to do is change the print statement to a function call (in 5_faro_new_print.py):

And if we run this...

So what's the error here? We fix that and the result (in 6_faro_floor_div.py) is:

But if we try to run this, the code starts running but seems to be looping indefinitely. (If you're running this in your own IPython Notebook, session, be prepared to interrupt the kernel.)

This is a job for pdb. By importing that module, we can, for instance, start the debugger at any time during execution.

And here's the final version:

Scaffolding

Interactive debugging with pdb or another IDE is all well and good, but these days I use an alternative: scaffolding. Let's start with the module print_whence.py. (It's in the unit directory with the demos.) Here it is:

When called, it prints out the name and line number of the file it's called from. That's not very useful from Jupyter Notebook:

But it is useful in demos (which we'll now illustrate).

I recommend its use in "scaffolding": Adding additional temporary code to a Python module to display its progress. I recommend the following pattern:

if 1 [ and condition(s) ]: printWhence([commentString]) [ print(*tagString*, *object*) ]+ if 1: quit() print()