Date: January 7th 2016
Last updated: January 18th 2016
My debugging to-date has been to print in a divide-and-conquer kind of way. The idea is to add the print statement in an area of buggy code, rerun the program, review the output, then move the print statement closer to the code that's producing the unexpected result.
The print method has always felt a little dirty to me. I have even thought that I might be the only one doing it. However, when I was looking for debugging options, I noticed that it's an extremely common approach. It's so common that some people have suggested a dubug_print() method (see the resource links below). EDIT: A useful debug print styled tool is available in the logging module.
In short, the print statement is not a recommended debugging option, but I still like it, and I think I will keep using it.
There are many alternatives to print. Below is a list of debugging options. The list includes development environments (IDE) with a graphical interface and several add-on programs to extend existing debuggers like pdb (e.g. pyclewn).
Over the next few days I am going to look at four non-IDE debuggers (bold) that seem popular.
- pdb (https://docs.python.org/2/library/pdb.html)
- pydbgr (https://pypi.python.org/pypi/pydbgr/0.2.6)
- pudb (http://pypi.python.org/pypi/pudb)
- Ipdb (https://pypi.python.org/pypi/ipdb)
- pdbpp (https://pypi.python.org/pypi/pdbpp/0.7.2)
- Bugjar (http://pybee.org/bugjar/)
- gdb (https://www.gnu.org/software/gdb/)
- PyDebug (http://georgejhunt.com/olpc/pydebug/pydebug/project_page.html)
- Pylint (http://www.pylint.org/)
- PyCharm (https://www.jetbrains.com/pycharm/)
- IDLE (https://www.gnu.org/software/gdb/)
- winpdb (http://winpdb.org/)
- pyclewn (https://pypi.python.org/pypi/pyclewn)