Best way to indicate debugging code in python?

[robinwatts]

Hi all,

First off, let me say that I'm only ~50% sure that I've found the right place to post this query. If it's in the wrong place, please accept my apologies. Any hints as to a better place to post would be much appreciated.

Try as I might, I can't find an obvious community forum for lgtm.com. I've seen references to discuss.lgtm.com, but that doesn't appear to exist anymore.

I'm one of the Ghostscript/MuPDF developers, and we've been using lgtm for a while to improve our codebase. It's been a largely worthwhile experience (certainly more so than some other static analysis tools we've tried), but I'm hitting a snag with some python code.

Let me say right off the bat that I am NOT a python coder, so it's entirely possible that there is something obvious I'm missing here.

So enough preamble, the problem...

Often, we have some debug code that needs to be disabled most of the time, but that we might want to switch on manually as part of hunting for particular bugs. In C we'd do this by doing something like:

/* Enable the following to help debug group blending. */
#undef DUMP_GROUP_BLENDS

at the top of the file, and then various #ifdef DUMP_GROUP_BLENDS sections throughout the following code. lgtm seems perfectly happy with this.

In python, no #ifdef's of course. Accordingly, we end up with various: "if 0:" sections. lgtm shows these up as 'Unreachable code'.

We could do:

dump_group_blends = 0

at the start and then do "if dump_group_blends:" for each block, but I believe lgtm complains about that too.

Is there a "best practice" formulation we should be using for such code to keep lgtm happy? Ideally, I'd really rather avoid having loads of annotating comments scattered through the code, but if we have to have one per such block, I guess we could...

Thanks in advance.

[tausbn]

This is an interesting question (and you've definitely asked it in the right venue!). I don't know of any particular "best practice" when it comes to this issue, but I do have a few thoughts.

First of all, you're right in thinking that doing debug = 0 followed by if debug: ... probably won't do the trick. In this case, I'm fairly certain that our analysis will be able to see through the deceit and figure out that debug is actually always false. However, more complicated expressions should be able to fool our analysis. For example, something like if 0*0: ... is enough to fool our analysis into not pruning the body of the if-statement (which makes the statements therein unreachable).

For a more principled approach (and assuming these scripts are run manually from the command line, say) I would suggest using something like the built-in argparse library. Then you can set up --debug as a flag that -- if present -- sets debug to True and defaults to False otherwise. You can even have multiple debug flags, if you so desire. In this way, you can both make the debug code more convenient to activate, and also make the code itself more informative, as you no longer have to wonder if a given if 0: ... block has to do with dumping the group blends or something else.

[robinwatts]

Thanks for the reply.

I am not running this from the command line - we're purely using lgtm.com to handle the testing/displaying of the code. It works so well, it seems silly to take on maintaining an installation ourselves.

You say that:

debug = 0
if debug:
    ...

will be seen through, but that:

if 0*0:
    ...

will not. Can I do:

debug = 0*0
if debug:
    ...

or am I being too hopeful?

Failing that, is there scope for the code accepting some sort of annotation to tell it to ignore that certain variables are constants?

debug = False // lgtm magic incantation

or something? Then I could have a list of #define equivalents at the top of each file all marked that way, and then just use if foo: blocks safely below. That's as neat a way as I can think of to work, but nothing is ever as simple as you'd hope...

Thanks again.

[tausbn]

I am not running this from the command line - we're purely using lgtm.com to handle the testing/displaying of the code. It works so well, it seems silly to take on maintaining an installation ourselves.

Ah, I think we may be talking past each other slightly. What I meant was: how are you invoking the Python scripts that you (sometimes) want additional debug output from?

From your description it sounds like you're manually editing the if 0: ... guarded blocks whenever you're debugging these scripts, and I was wondering if there was a more principled approach that would make your life easier. If the scripts are usually run manually, then I would definitely advocate using something like argparse. 🙂

[...] Can I do:

debug = 0*0
if debug:
    ...

or am I being too hopeful?

I just tested the above approach, and it works as you had hoped: no "Unreachable code" warnings appear. 🎉

Failing that, is there scope for the code accepting some sort of annotation to tell it to ignore that certain variables are constants?

debug = False // lgtm magic incantation

or something? Then I could have a list of #define equivalents at the top of each file all marked that way, and then just use if foo: blocks safely below. That's as neat a way as I can think of to work, but nothing is ever as simple as you'd hope...

Alas, we currently don't have such machinery in place. It certainly could be added (it is how we currently implement the # lgtm suppression comments), but the tricky bit is weaving it into the analysis appropriately. This is made more complicated by the fact that there are several places where we would have to take this into account (in other words, there are several places where we might identify that a piece of code is unreachable).