一个好的集成开发环境（IDE）附带的调试器是开发人员能够拥有的最强大的工具之一，但并不是每个人都在使用一个带有很棒代码调试器的集成发环境（IDE）。作为程序员，在调试 Python 代码时，你觉得最好用的调试器有哪些？如果没有的话，不妨试试使用 IPython 作为调试器吧。
以下为译文：
Tenderlove（Ruby和Rails的核心开发人员之一）写了一篇很棒的文章，叫做“I am a puts debuggerer”，当我还在玩Ruby的时候，我很喜欢这篇文章。这篇文章的重点是想告诉大家：在许多情况下，你不需要一个成熟的调试器。别误会我（或者Tenderlove）的意思，我认为，一个好的集成开发环境（IDE）附带的调试器是开发人员能够拥有的最强大的工具之一！它能让你可以很轻松地在代码中放置断点、在stack trace中移动、或者动态地检查和修改变量。它也使开发人员在大型代码库上工作更加轻松，并且可以帮助新手程序员加快新项目的进度。
然而，今天的人们仍然会使用print语句来调试他们的代码。我总是这样做，因为打印出一个变量既快又容易。“我要开始调试会话”这句话听起来很沉重，而“我认为这个变量有问题。我想打印出来看看！”就轻松多了。下面就是我们用5分钟就能写出的一个print语句的例子：
print(a_varible)
...
if foo:
print(">>>>>>>>>>>>>>Inside 3rd IF")
...
print(">>>>>>>>>>>>>>Inside 37th IF")
print(">>>>>>>>>> #@!?#!!!")
上面的代码看起来很熟悉吧？使用print语句进行代码调试是毫无问题的。很多时候，你要做的只是找出Bug。有时候，这也是你能运用的调试代码的唯一方法。因为在不影响用户使用的前提下，你很难将调试代码添加到生产环境代码中。然而，仅仅添加一些print语句，然后查看日志应该不会造成什么问题。
并不是每个人都在使用一个带有很棒代码调试器的集成发环境（IDE）。2019年Stack Overflow开发者调查报告显示：30.5%的开发人员使用Notepad++，25.4%的开发人员使用Vim，23.4%的开发者使用Sublime Text。这些都是文本编辑器！尽管我看到开发人员在使用Vim时比大多数使用PyCharm或VS Code的用户更有效率，但是要记住一个文本编辑器并不会带有强大的代码调试器。要调试Python代码，你当然可以使用标准的Python调试器pdb，但是现在你有一个更好的选择：那就是使用IPython作为调试器。
我使用VS Code已经快两年了，但我不记得上次使用其内置的调试器是什么时候。我大部分的调试工作都是在IPython中完成的。以下是我的调试方法：
将IPython会话嵌入到代码中
对我而言，最常用的做法是在代码中嵌入一个IPython会话。你只需要在代码中插入以下两行就可以做到：
from IPython import embed
embed()
我喜欢把这两行代码放在同一行，像下面这样：
from IPython import embed; embed()
这样的话，我只需要敲一次键盘就能把它移除掉。而且，在Python中，将多个语句放在同一行是一种坏习惯，因此所有的code linter都会将这行作为一个问题标注出来，这样的话，当调试完成后，调试就不会忘记把它移除??。
当你运行代码并且解释器到达带有embed（）函数的行时，它将打开一个IPython会话。你可以仔细查看代码中发生了什么。当你完成后，你只需要使用Ctrl+d关闭会话，代码将继续执行。这种方法的一个优点是，当你关闭IPython会话时，你在IPython中所做的所有修改都将保存下来。因此，你可以用这种方式对变量或函数进行修改（甚至可以用一些简单的日志来修饰函数），并查看其余代码的行为。
下面是使用embed（）的简短演示。假设我们有以下代码：
a = 10
b = 15
from IPython import embed; embed()
print(f"a+b = {a+b}")
下面是我们运行它时发生的情况：
如上所见，我更改了a变量的值，当我关闭IPython会话后，a的新值保留下来了。
在代码中放置断点
如果你想查看在给定代码行上发生的情况，在代码中嵌入一个IPython会话是不错的做法。但是它不能像真正的调试器那样，让你可以执行下一行代码。所以更好的办法是在代码中放置一个断点。从Python 版本3.7开始，有一个新的名为breakpoint（）的内置函数可以用来放置断点。如果你使用的是较低版本的Python，你可以通过运行以下代码来实现同样的效果：
import pdb; pdb.set_trace()
Python的默认调试器（pdb）相当初级。就像在标准Python REPL（—种交互式解释器环境。R-read)、E-evaluate)、P-print)、L-loop)中一样，它没有语法突出显示或自动缩进的功能。一个更好的选择是ipdb。它将使用IPython作为调试器。要启用它，需要将上面代码中的pdb替换成ipdb：
import ipdb; ipdb.set_trace()
还有另一个有趣的调试器PDB++。它有一组不同于ipdb的特性，例如，一个不断显示代码当前位置的粘滞模式。
不管你最终使用哪个调试器，它们都有一组相当标准的命令。你可以通过调用next命令（或者只是n命令）来执行下一行，通过调用step（或s）命令进入函数内部，使用continue（或c）命令继续执行直至下一个断点，使用l或ll命令显示当前代码执行的位置，等等。如果你是一个CLI（命令行接口）类型调试器的新手，那么“使用Pdb调试Python代码教程”应该对你掌握它们会有帮助。
%run -d filename.py
IPython还有另外一种方式启动一个调试器。你不需要像前面那样修改任何文件的源代码。你只需要运行%run -d filename.py这个神奇的命令，然后IPython将执行filename.py文件并在其第一行设置一个断点。作用等同于将import ipdb; ipdb.set_trace()手动放入filename.py文件中，并且使用python filename.py命令来运行它一样。
如果要将断点放在第一行之外的其他位置，可以使用-b参数。以下代码将断点放置在第42行的位置：
%run -d -b42 filename.py
记住，这里指定的行必须包含实际执行某些操作的代码。不能是空行或注释行！
最后，可能存在这样一种情形：你希望将断点放在一个不是你将要运行的文件中。比如说，某个bug可能隐藏在一个导入的模块中，而你不想再键入100次next命令就可以执行到那里。-b参数可以接受一个文件名，后跟一个冒号和一个行号，以指定要将断点确切放置到的位置，修改后的代码如下：
%run -d -b myotherfile.py:42 myscript.py
上面的代码将在名为myotherfile.py的文件的第42行设置一个断点，然后开始执行myotherfile.py文件。一旦Python解释器到达myotherfile.py，它将在断点处停止。
事后调试（Post-mortem debugging）
IPython共有176项特性。事后调试是最好的特性，至少对我来说是这样。假设你正在运行一个长期运行的脚本，在运行了15分钟后，它突然崩溃了。那么，你能做的是设置一些断点，重新运行它，然后再等待15分钟，看看发生了什么吗？如果你用的是IPython，只要调用一个神奇的命令%debug，你就不必等待了。%debug将加载最后一个异常发生时的stack trace，并且启动调试器（Python将最后一个未处理的异常存储在sys.last_traceback变量中）。这是一个很好的特性，它可以让你直接启动调试器，节省了几个小时的重新运行一些命令的时间。
如果使用的是标准pdb调试器，则可以通过运行import pdb; pdb.pm（）命令来实现相同的效果。
使用%pdb自动启动调试器
让调试更加方便的唯一方法是在发生异常时自动启动调试器。IPython中的这个神奇的命令 - %pdb就能实现这一点。
如果运行%pdb 1（或%pdb on）命令，调试器将在每个未处理的异常上自动启动。你可以使用%pdb 0或关闭%pdb on命令关闭这个功能。不带任何参数运行地运行%pdb将在打开和关闭自动调试器之间进行切换。
