CODEWITHSUNDEEP
pythondebuggingvim
Somebody still uses you MS-DOS
Somebody still uses you MS-DOS

Reputation: 13349

How do you avoid leaving debugger print/pdb statements in python open source apps when you're debugging them and just finish?

Sometimes when developing using open source software, you need to read it's source code (specially zope/plone). A lot of times I need to write print statements, or debug calls (import pdb), or comment try/except clauses, you name it.

Sometimes I have a lot of files opened when trying to find an issue, and sometimes I forget to remove these print/debug alterations.

So, my question is: how do you keep yourself organized when doing it? Do you write "TODOs" along the modifications and search for them later, do you keep everything opened in your editor and when you find what you were looking for you just revert the files (This approach isn't useful when you're searching for a really big problem that needs days, you need to turn off your computer and return the other day)? Or you just don't do nothing since print statements in development environment is nothing to worry about?

I'm using Vim. I'm just interested to know how other programmers treat this issue.

Upvotes: 4

Views: 1378

Answers (5)

pourhaus
pourhaus

Reputation: 616

I can give you three suggestions:

  1. Do not remove debugger statements. By this, I mean leave them in, but make them conditional on being in debug mode:
# Set this to True to enable Debug code
XYZ_Debug = False

if XYZ_Debug:
    do_debugging()

Oh, and if the debugging code is just to print things out, you should get familiar with logging (PyMOTW). If you are using logging, you could:

import logging

# Set this to True to enable debug
XYZ_Debug = False

log = logging.getLogger("XYZ")
log.setLevel(logging.DEBUG if XYZ_Debug else logging.INFO)


log.debug("debug output")
  1. Put the same unique tag (in a comment) after each line, or near each block:
do_debug_code() # XYZZY

I then use Emacs' Ibuffer feature, mark all Python buffers then search for occurrences of this tag. Using some combination of find/grep/sed as in other answers would work as well.

  1. If you are using Mercurial and know Mercurial Queues (or might want to learn them), maintain the debug code as a patch in your queue. When you are ready for "production"; or push of the current changes; pop the patch containing the debug code and go. You could achieve something like this outside of version control with diff and patch.

Upvotes: 1

JS.
JS.

Reputation: 16167

I used to run into that problem a lot. Now, as part of my check-in process, I run a find/grep script combo that looks for my debugging statements. The only caveat is that I must keep my added debugging statements consistent so grep can find them all.

something like this:

## pre-checkin_scan.bin
find . -name "*.py" -exec grep -H --file=/homes/js/bin/pre-checkin_scan_regexp_list.grep {} \;



## pre-checkin_scan_regexp_list.grep
## (The first pattern is to ignore Doxygen comments)

^##[^@]
pdb
^ *print *( *" *Dbg
^ *print *( *" *Debug
^ *debug

Upvotes: 4

Keith
Keith

Reputation: 43054

I also develop Python with Vim. I have never had to substantially modify the source code for debugging. I do sometimes put debugging print statements, and I have the habit of putting "# XXX" after every one. Then when I want to remove them (before a commit), and just search for the XXX and delete those lines.

For exceptions, I have arranged to run my code in the Vim buffer with an external interpreter that is set up to automatically enter the debugger on any uncaught exception. Then I'm placed automatically in the code at the point the exception occured. I use a modified debugger that can also signal Vim (actually GTK Gvim) to open that source at that line.

Caught exceptions should report meaningful errors, anyway. It is considered by many to be bad practice to do things like:

try: ... some code except: handle everything

Since you probably aren't actually handling every possible error case. By not doing that you also enable the automatic debugging.

Upvotes: 1

Tauquir
Tauquir

Reputation: 6913

Well +1 for starting this discussion. Yes sometime this happen to me. I left those pdb and commit the code to the central code base, git. I use 'emacs'. So, Before commit the code I usually search for pdb in the file. But it is hectic checking each file.So, Before committing the code I usually check the diff very carefully. I am also finding the better way to resolve this issue.

Upvotes: 2

AndiDog
AndiDog

Reputation: 70208

In case of my own projects, the source code is always in version control. Before committing, I always check the graphical diff so that I can see what has changed, what the commit message should be and whether I can split up into smaller commits. That way, I almost always recognize temporary garbage like print statements. If not, I usually notice it shortly afterwards and can do an uncommit if I haven't yet pushed (works for DVCS like git and bzr, not with subversion).

Concerning problems that take multiple days, it's just the same thing. I don't commit until the problem is solved and then look at the diff again.

A text editor that allows editing within the graphical diff view would be really helpful in these cases, but I'm mostly using Eclipse, which doesn't support that.

Upvotes: 4

Related Questions