在Python圈子里，毫无疑问鸭子类型的实现方式更符合Pythonic的风格，这完全贴合Python那句经典的设计哲学——“如果它走起来像鸭子、叫起来像鸭子，那它就是鸭子”。

先聊聊你给出的两种写法：

类型检查写法的问题 #

首先你的类型检查代码里有个小逻辑错误，应该是if not isinstance(document, SHA256Hashable):才对（否则当前代码是符合类型时抛异常，逻辑完全反了）。但即便修正后，这种写法也不够地道：它把使用范围死死限制在了SHA256Hashable类的实例上，哪怕某个对象不是这个类的子类，但完完整整实现了sha256_hash()方法，也会被直接拒绝，这就浪费了Python动态类型的灵活性。

鸭子类型写法的优势 #

而第一种“尝试调用方法，失败了再处理异常”的写法，才是Python社区推崇的EAFP原则（Easier to Ask for Forgiveness than Permission，请求原谅比请求许可更容易）的典型体现。不过可以给它做个小优化，让错误提示更友好：

class MerkleTree:
    def method(self, document):
        try:
            hash_ = document.sha256_hash()
        except AttributeError:
            raise TypeError(f"需要实现sha256_hash()方法的对象，实际传入的是{type(document).__name__}类型") from None
        do_smth_with_hash(hash_)

这里加上了具体的错误描述，还用from None隐藏了原AttributeError的上下文，让使用者能一眼看懂问题出在哪。

为什么说这种写法更Pythonic？

• 灵活性拉满：不需要强制继承某个类或实现某个接口，只要对象有sha256_hash()方法就能用，后续扩展新类型时完全不用修改MerkleTree的代码。
• 代码更简洁：省去了冗余的类型判断逻辑，把注意力放在实际要做的事情上。
• 符合动态类型特性：Python本身就是动态类型语言，鸭子类型的写法完美契合这种特性，而不是生硬地套静态类型的检查逻辑。

特殊场景的折中方案 #

当然，如果是团队协作需要严格的接口规范，或者你希望明确约束输入类型，也可以用抽象基类（ABC）来做：

from abc import ABC, abstractmethod

class SHA256Hashable(ABC):
    @abstractmethod
    def sha256_hash(self):
        pass

class MerkleTree:
    def method(self, document):
        if not isinstance(document, SHA256Hashable):
            raise TypeError(f"预期传入SHA256Hashable实例，实际得到{type(document).__name__}")
        hash_ = document.sha256_hash()
        do_smth_with_hash(hash_)

但这属于特殊场景的选择，常规情况下，鸭子类型的写法依然是Python的首选。

内容的提问来源于stack exchange，提问作者busukxuan