如何处理“鸭子打字”在Python中？

Question

我通常想让我的代码尽可能通用。我目前正在编写一个简单的库，这次能够在我的库中使用不同的类型感觉格外重要。

一种方法是强制人们子类化“接口”类。对我来说，这感觉更像 Java，而不是 Python，并且在每个方法中使用 issubclass 听起来也不是很诱人。

我的首选方法是善意地使用该对象，但这会引发一些AttributeErrors。我可以将每个危险调用包装在 try/ except 块中。这似乎也有点麻烦：

def foo(obj):
    ...
    # it should be able to sleep
    try:
        obj.sleep()
    except AttributeError:
        # handle error
    ...
    # it should be able to wag it's tail
    try:
        obj.wag_tail()
    except AttributeError:
        # handle this error as well

我应该跳过错误处理并期望人们只使用具有所需方法的对象吗？如果我做了像 [x**2 for x in 1234] 这样的愚蠢事情，我实际上会得到一个 TypeError 而不是 AttributeError （整数不是iterable）所以必须在某个地方进行一些类型检查——如果我想做同样的事情怎么办？

这个问题是开放式的，但是以干净的方式处理上述问题的最佳方法是什么？有没有既定的最佳实践？例如，上面的可迭代“类型检查”是如何实现的？

编辑

虽然 AttributeErrors 很好，但本机函数引发的 TypeErrors 通常会提供有关如何解决错误的更多信息。以此为例：

>>> ['a', 1].sort()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() < str()

我希望我的图书馆尽可能有帮助。

Answer 1

我不是 python 专业人士，但我相信除非当参数没有实现给定方法时您可以尝试替代方法，否则您不应该阻止抛出异常。让调用者处理这些异常。这样，您就会向开发人员隐藏问题。

正如我在 干净代码，如果您想搜索集合中的项目，请不要使用（列表的）ìssubclass 测试您的参数，而是更喜欢调用getattr(l, "__contains__")。这将使使用您代码的人有机会传递一个不是列表但定义了 __contains__ 方法的参数，并且效果应该同样良好。

因此，我认为您应该以抽象、通用方式进行编码，并尽可能施加很少的限制。为此，您必须做出尽可能少的假设。然而，当你面对无法处理的事情时，引发异常并让程序员知道他犯了什么错误！

Answer 2

如果您的代码需要特定的接口，并且用户传递一个没有该接口的对象，那么十分之九的情况是不适合捕获异常的。大多数时候，当涉及到接口不匹配时，AttributeError 不仅是合理的，而且是预料之中的。

有时，出于以下两个原因之一捕获 AttributeError 可能是合适的。您要么希望接口的某些方面是可选的，要么希望抛出更具体的异常，可能是特定于包的异常子类。当然，如果您没有诚实地处理错误和任何后果，那么您永远不应该阻止抛出异常。

所以在我看来，这个问题的答案必须是特定于问题和领域的。从根本上来说，这是一个使用 Cow 对象而不是 Duck 对象是否应该起作用的问题。如果是这样，并且您处理了任何必要的界面捏造，那就没问题了。另一方面，没有理由显式检查某人是否向您传递了 Frog 对象，除非这会导致灾难性的失败（即比堆栈跟踪更糟糕的情况）。

也就是说，记录你的界面总是一个好主意——这就是文档字符串（以及其他东西）的用途。仔细想想，在大多数情况下抛出一般错误并在文档字符串中告诉用户执行此操作的正确方法比尝试预见用户可能犯的每个可能的错误并创建自定义错误消息要有效得多。

最后需要注意的是 - 您可能在这里考虑的是 UI - 我认为那是另一个故事了。最好检查最终用户提供的输入，以确保它不是恶意的或严重畸形的，并提供有用的反馈而不是堆栈跟踪。但对于库或类似的东西，你真的必须相信使用你的代码的程序员会明智地、尊重地使用它，并理解 Python 生成的错误。

Answer 3

如果您只想让未实现的方法不执行任何操作，您可以尝试这样的操作，而不是多行 try/ except 构造：

getattr(obj, "sleep", lambda: None)()

但是，这作为函数调用并不一定显而易见，因此也许：

hasattr(obj, "sleep") and obj.sleep()

或者如果你想在调用某些东西之前更加确定它实际上可以被调用：

hasattr(obj, "sleep") and callable(obj.sleep) and obj.sleep()

这种“先看后跳转”模式通常不是在 Python 中执行此操作的首选方法，但它是完美的可读且适合单行。

当然，另一种选择是将 try/ except 抽象为单独的函数。

Answer 4

好问题，而且相当开放式。我相信典型的 Python 风格是不进行检查，无论是使用 isinstance 还是捕获单个异常。当然，使用 isinstance 是一种非常糟糕的风格，因为它破坏了鸭子类型的全部意义（尽管在基元上使用 isinstance 是可以的——一定要检查整数输入的 int 和 long，并检查字符串的 basestring (base str 和 unicode 的类）。如果您进行检查，则应该引发 TypeError 。

不检查通常是可以的，因为它通常会引发 TypeError 或 AttributeError ，这正是您想要的（尽管它可能会延迟客户端出现这些错误）。代码难以调试）。

您看到 TypeErrors 的原因是原始代码会引发它，实际上是因为它执行了 isinstance，如果某些内容不可迭代，则 for 循环会被硬编码为引发 TypeError。

Answer 5

首先，您问题中的代码并不理想：

try:
    obj.wag_tail()
except AttributeError:
    ...

您不知道 AttributeError 是来自 wag_tail 的查找还是发生在函数内部。您想要做的是：

try:
    f = getattr(obj, 'wag_tail')
except AttributeError:
    ...
finally:
    f()

编辑：kindall 正确地指出，如果您要检查这一点，您还应该检查 f 是否可调用。

一般来说，这不是Pythonic。只需调用并让异常过滤下来，堆栈跟踪的信息就足以解决问题。我认为您应该问自己，重新抛出的异常是否足够有用来证明所有这些错误检查代码的合理性。

对列表进行排序的情况就是一个很好的例子。

• 列表排序非常常见，
• 其中很大一部分会发生传递不可排序的类型，并且
• 在这种情况下抛出 AttributeError 非常令人困惑。

如果这三个标准适用于您的问题（尤其是第三个），我同意构建漂亮的异常重新抛出器。

您必须平衡这样一个事实：抛出这些漂亮的错误将使您的代码更难以阅读，从统计上来说，这意味着您的代码中存在更多错误。这是一个利弊权衡的问题。

如果您需要检查行为（例如 __real__ 和 __contains__），请不要忘记使用 collections 中找到的 Python 抽象基类、io 和数字。