尽管已经回答了，但这太长了，无法评论，所以我将添加另一个答案。

通常，执行类型检查有两个原因：确保您的函数实际完成，以及避免因输出错误而导致下游故障调试困难。

对于第一个问题，答案总是恰当的-EAFP是常规方法。你不必担心糟糕的输入。

第二次。。。答案取决于您的正常用例，并且您确实担心不好的输入/错误。当坏输入总是生成异常时(其中“坏输入”可能仅限于应用程序预期生成的坏输入类型)，EAFP仍然是合适的(而且更容易，也更易于调试)。但是如果错误的输入有可能产生有效的输出，那么LYBL可能会让你以后的生活更轻松。

示例：假设您调用square()，将该值放入字典中，然后(很多时候)从字典中提取该值并将其用作索引。当然，索引必须是整数。

平方(2)==4，是有效整数，因此是正确的。正方形('a')将始终失败，因为'a'*'a'无效，并且将始终引发异常。如果只有这两种可能性，那么您可以安全地使用EAFP。如果您得到了错误的数据，它将抛出一个异常，生成一个回溯，您可以使用pdb重新启动，并得到一个很好的错误指示。

但是。。。假设你的应用程序使用了一些FP。这是可能的(假设你有一个虫子！)！当然不是正常的操作)让你意外地调用square(1.43)。这将返回一个有效值-2.0449左右。你在这里不会有例外，所以你的应用程序会很高兴地把2.0449放进字典里。很久以后，你的应用程序会将这个值从字典中提取出来，并将其用作列表的索引，然后崩溃。你会得到一个回溯，你会用pdb重新启动，意识到这对你毫无帮助，因为这个值是很久以前计算出来的，你不再有输入，也不知道数据是怎么得到的。而且调试起来也不好玩。

在这些情况下，您可以使用asserts(LYBL的特殊形式)提前移动这些类型的bug的检测，或者显式地执行。如果你从来没有一个bug调用这个函数，那么任何一个都可以工作。但如果你这样做。。。然后你会真的很高兴你人工检查了接近失败的输入，而不是自然地在你的应用程序中随机的一些地方。