上面的一段代码有木有很像你平时调试代码的样子？好吧，我原来也是这样。老实说，这并不坏。敲一些print进去，运行代码，然后看会发生什么。你肯定需要在输出里面翻来翻去的，但你能找到你想要的结果。至少，当你知道你想要什么。不过通常不是这样，如果你知道检验些什么，你可能就不会需要打印那些输出了。反而，你把一些print代码扔到你觉得可能有问题的地方，然后反复的移动这些语句，知道发现真正的bug。就是二分查找嘛！

谢天谢地，有一个更好的方法。从C语言开始，有一类被称为调试器的工具在每种语言里都出现了。Python也不例外，里面就有一个默认的调试器。还有一些社区开发的很酷的调试器。在接下来的内容里，我会谈谈一些比较流行的调试工具。

Pdb

首先来说Python里内建的调试器，pdb。它利用一个简单的命令行界面，还有很多你在用调试器时用得上的功能。帮助系统能为你指出你能运行的命令，比如单步调试代码，操纵调用栈和设置断点。

一些它缺少的功能：按tab能让本地变量自动补全和让代码和栈追踪更好看的配色和布局。

不管你最后决定使用哪种调试器，pdb是值得你花时间了解它的，有两个原因：1）它在Python里总是可用的 2）很多其他的调试器的功能是pdb的超集，先学pdb能让你更快的学习其他的调试器。

总之，如果有更好的还是用别的调试器吧。

Pydbgr

接下来是pydbgr（支持Python 3.2+ 版本），这个项目是对pydb调试器的重写。它提供了与pdb非常相似的一组命令，尽管如此，有一些有用的别名比如’u’表示’up’是没有的。

这个调试器做得很好的一点是能够对执行流向进行细粒度地控制。你可以输入命令并指定命令重复执行的次数。你也可以告诉调试器在某些事件触发时停止，比如函数调用和返回，这能让你减少很多调试的步数。

调试器的另一个特性是提供了其他调试器没有的功能，它能通过像examine 和disassemble这样的命令来进行非常低级别的符号检查。说实话，我不太确定这个功能在web开发里被证明很有用，但它能让你的工作很不同。

总之：它对pdb添加的特性我觉得不是对web开发很有用的。

pudb

这个调试器里最明显的亮点就是它在终端里融合了一个迷你图形界面。这很正确，这不是一个分开的窗口，这是在终端里面。除了一组用于强调的默认颜色（它能够定制或选择一组默认的主题），这在调试器的交互上是一个新颖的尝试。

左边的面板显示当前文件的代码（或者你在栈里上下移动的其他文件）。导航栏非常棒，包含箭头键（以及’hjkl’对喜爱vim的群众），搜索，并且能用模糊查询打开其他的模块。能把这些简单的行为用一个快捷键结合起来执行光标位置的代码，并且有非常直观和友好的方式来单步调试程序。当然，pudb仍然提供了正常的断点和单步命令使你能随心所愿地控制代码的执行。

在右边，有几个面板来追踪当前的本地变量，栈，和存在的断点。这在你键入 locals()，whereh或者用tab完成来反射当前框架时与典型的终端调试器非常不一样，

这个调试器的另一个优点是它支持事后分析。当你命中一个异常，调试器会用一个很快的键来提示你这个异常。它也能让你直接跳到发生了异常的那一行，同时能让栈和变量保持完好。

总结：拥有这堆调试器里最好的用户体验；对于栈追踪特别有用。

Ipdb

最后一个就是iPython里的ipdb。就像它的 *pdb 的兄弟们，它的界面是一个简单的命令行并且它的帮助系统是个非常值得深入研究的地方。让这货与众不同的是它使用了一个iPython shell，所以所有的tab 完成和对象反射的功能都用，能帮你发现究竟发生了什么。把这些与很棒的语法高亮和一个拥有最好的格式化的where命令结合起来，就组成了一个干掉bug的完美工具。

总结：这是最棒的一个也是本人的最爱。

我会提到，根据情况，我切换到pudb。它确实在浏览代码是如何运行方面是最棒的（比如当你必须钻研一个除了毛病的第三方库）。而我为什么最倾向于ipdb，是因为大部分时候我对代码都很熟悉，并不需要一个大图片。我需要知道在一个指定的函数里是什么状态。把它们结合起来，就是超级超级NB的东西啦！