Ezio Melotti <ezio.melo...@gmail.com> added the comment: > Hadn’t though about coverage. Will mention it and add a link > to the devguide part that talks about it.
Is devguide/coverage.html#using-coverage-py generic enough? We don't have to duplicate the coverage documentation though, mentioning the tool and what it does, provide a couple of simple example and a link to the coverage doc should be enough. Talking about unittest and coverage is not strictly about debugging (you don't have any bug yet), but it's useful because it might reveal bugs earlier and avoid debugging sessions later. This might also go with pyflakes and friends, since they both provide a way to detect bugs earlier. > - running Python in gdb This is somewhat orthogonal, but the devguide/gdb page doesn't say how to start running Python in gdb (it might be obvious to people used to use gdb, but it should still be mentioned). > If error not obvious from quick read, in a 20 line function, > add print around line 10. I usually print variables in order of suspiciousness, i.e., I usually have an idea about where the problem might be, if it's not there I move to the next suspect. This also applies when I know which variable is "wrong" but I don't know where it got wrong: I just add the prints around the most suspicious function that might have changed. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12913> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
