17370845950

最稳妥的方式是直接调用 len() 并捕获 TypeError，因为即使 len 存在且可调用，其返回值非法（如负数、非整数）仍会导致 len() 抛异常，而异常处理最终必不可少。

直接检查 __len__ 方法是否存在

最稳妥的方式不是调用 len() 再捕获异常，而是提前确认对象是否实现了 __len__。Python 的 len() 本质就是调用对象的 __len__ 方法并要求返回非负整数，所以只要该方法存在且可调用，len() 就不会因“不支持”而报 TypeError。

但要注意：hasattr(obj, '__len__') 不够可靠——有些对象（比如某些 C 扩展类型或自定义描述符）可能有 __len__ 属性但不可调用，或者返回值非法（如负数、非整数），此时 len() 仍会抛异常。

• 推荐用 getattr(obj, '__len__', None) 获取方法，再用 callable() 判断是否可调用
• 如果只需要快速判断且能接受极少数误判，hasattr(obj, '__len__') 更简洁
• 避免用 isinstance(obj, collections.abc.Sized)：虽然语义准确，但会触发 ABC 的注册检查和元类逻辑，对性能敏感场景（如高频循环）有开销

用 try/except 捕获 TypeError 更实际

在多数业务代码中，“先检查再调用”不如“直接调用，出错再处理”来得简洁可靠。因为即使 __len__ 存在且可调用，它仍可能在运行时抛出 TypeError（比如返回 float 或 None），最终还是要靠异常处理兜底。

示例：

def safe_len(obj):
    try:
        return len(obj)
    except TypeError:
        return None  # 或抛出自定义异常、返回 -1 等

• 只捕获 TypeError，不要用裸 except: —— len() 不会抛 ValueError 或 AttributeError，捕其他异常会掩盖真实问题
• 注意：某些对象（如生成器、某些迭代器）没有 __len__，但 len() 报的也是 TypeError，不是 AttributeError
• 如果函数需频繁调用，且多数输入确实支持 len()，try/except 的性能反而优于属性检查

collections.abc.Sized 的适用边界

isinstance(obj, collections.abc.Sized) 是语义最清晰的判断方式，符合 Python 的抽象基类设计哲学。但它依赖 __subclasshook__ 和注册机制，因此有几点限制：

• 内置类型（如 list、str、dict）默认是 Sized 的子类，没问题
• 用户自定义类若未显式继承或注册，即使实现了 __len__，isinstance(..., Sized) 也可能返回 False
• 第三方库中部分类型（如 numpy.ndarray）虽支持 len()，但未注册为 Sized，导致检查失败
• 在类型检查工具（如 mypy）中，Sized 是推荐的静态提示方式，但运行时不一定等价

容易被忽略的细节：__len__ 返回值必须是非负整数

即使对象有可调用的 __len__，如果它返回负数、浮点数、None 或其他类型，len() 仍会立刻抛 TypeError: 'xxx' object cannot be interpreted as an integer 或类似信息。

这意味着：仅检查 __len__ 存在性或可调用性，并不能 100% 保证 len() 成功。真正安全的做法，始终是执行 len() 并捕获 TypeError——除非你完全信任该对象的实现。