__repr__ 应返回可被 eval() 解析的字符串或明确调试标识,如 "User(name='alice', age=30)";__str__ 面向用户,简洁可读;__eq__ 必须配对实现 __hash__(设为 None 或基于不可变属性);__len__ 必须返回非负 int;__bool__ 优先于 __len__ 控制真值。

__str__ 和 __repr__ 别混用,尤其别在 __repr__ 里返回非合法 Python 表达式
很多人把 __repr__ 当成“更详细的 __str__”,结果返回类似 " 的字符串——这看起来清晰,但违反了 __repr__ 的设计契约:它应该尽可能返回一个能被 eval() 解析还原对象的字符串(或至少是明确、无歧义的调试标识)。实际中,除非对象确实支持从字符串重建(比如 datetime),否则优先用格式化占位符加类名和关键属性,例如 "User(name='alice', age=30)"。如果做不到,就退回到带内存地址的兜底写法:f"{type(self).__name__}(0x{id(self):x})"。
-
__str__面向终端用户,可读、简洁、可本地化;__repr__面向开发者,明确、无歧义、宜调试 - 日志、
print()、交互式解释器默认调用__str__;repr()、容器__repr__、异常 traceback 默认调用__repr__ - 若只实现一个,优先实现
__repr__;__str__缺失时会 fallback 到__repr__,但反过来不行
__eq__ 必须配对实现 __hash__,否则实例无法进 set 或作 dict 键
定义 __eq__ 时忘了重写 __hash__,是导致 TypeError: unhashable type 的高频原因。Python 规则很明确:只要重写了 __eq__,且逻辑上对象是可变的(或你不想让它可哈希),就必须显式设 __hash__ = None;如果对象逻辑不可变(如自定义的 Point),则应提供一致的 __hash__ 实现,且必须确保相等的对象哈希值相同。
- 错误示范:
def __eq__(self, other): return self.x == other.x and self.y == other.y,但没动__hash__→ 实例自动失去哈希能力 - 正确做法一(不可哈希):
__hash__ = None - 正确做法二(可哈希):
def __hash__(self): return hash((self.x, self.y)),且确保x、y不可变 - 注意:继承自
object的默认__hash__基于id(),一旦你定义了__eq__,这个默认行为就被禁用
__len__ 返回值必须是非负整数,且不能是 float 或 None
__len__ 的返回类型约束非常严格:必须是 int,且不能为负数。返回 float、None、字符串甚至 np.int64 都会触发 TypeError: 'xxx' object cannot be interpreted as an integer。这不是隐式转换问题,而是 CPython 底层直接检查类型。
- 常见踩坑:用 NumPy 数组长度做返回值 →
np.int64不被接受;应显式转int(len(self._data)) - 空容器应返回
0,不是None或False - 如果长度计算代价高(比如远程分页计数),不要在
__len__里做,改用显式方法如.count(),避免用户误以为len(obj)是 O(1)
__bool__ 和 __len__ 的优先级关系容易被忽略
当同时定义了 __bool__ 和 __len__,Python 会优先调用 __bool__ 来判断真值;只有前者未定义时,才回退到 __len__。这意味着如果你只重写了 __len__ 却期望 if obj: 按长度非零来判断,那没问题;但一旦你加了 __bool__,哪怕只是临时调试打了个 return True,整个真值逻辑就变了,且不会报错——这是静默行为变更。
立即学习“Python免费学习笔记(深入)”;
- 典型陷阱:在基类里加了
__bool__返回self.is_active,子类只重写了__len__,结果子类实例的真假判断完全不看长度 - 建议:除非有明确语义差异(如“存在性” vs “非空性”),否则不要同时实现两者;若必须,确保逻辑自洽
- 调试时可用
help(bool)或查__bool__是否存在于dir(obj)中,快速定位谁在控制真值
__hash__ 可能让对象在字典里消失,一个越界的 __len__ 返回值会直接中断解释器执行——边界不在文档里,而在 CPython 的类型检查逻辑中。










