Python中dunder方法访问规则及@property装饰器关联问题咨询

你提供的测试代码运行逻辑没问题，对应输出也符合预期：

number = 5

print(number.__class__)
print(number.__str__())
print(number.__add__(1))

# 输出
<class 'int'>
5
6

下面针对你的三个疑问逐一解答： #

1. __class__是否通过@property装饰器实现属性式访问？ #

不是。__class__是CPython底层实现时内置在对象内存结构中的元数据属性，访问时直接从对象的固定内存字段读取值，走的是底层的专属属性查找逻辑，和Python层面用@property装饰器实现的属性完全是两个实现路径。只有自定义类中用户自己封装的属性式访问才会用到@property，这类内置的特殊属性都是解释器层面直接实现的。 #

2. __str__、__add__均为未使用@property的方法，需要按方法形式传参调用的认知是否正确？ #

基本正确。内置类型的__str__和__add__都是标准的实例方法：__str__仅依赖实例自身的状态生成字符串，不需要额外传入参数（隐含的self参数由解释器自动传入）；__add__对应加法运算符逻辑，需要传入另一个参与运算的操作数，二者都没有被@property修饰，因此必须加括号、按需传参调用。 #

3. 可以通过@property改造__str__为属性访问，是否说明dunder方法的访问形式是随意的？ #

这个推论是错误的。
技术层面你确实可以在自定义类中给__str__加@property装饰器，手动直接访问obj.__str__的时候可以正常拿到返回值，但这严重违反Python的语言约定，实际开发中完全不推荐这么写：

• Python解释器调用这些dunder钩子的时候都是按方法形式调用的，比如执行str(obj)时，解释器会尝试调用obj.__str__()，如果你的__str__是@property生成的字符串而非可调用对象，会直接抛出TypeError，导致所有依赖这个钩子的内置函数、运算符逻辑全部失效。
• dunder方法的访问形式有明确的设计逻辑：仅表示对象固有元数据、不需要额外计算的内容设计为属性（比如__class__、__doc__）；对应操作钩子、需要执行计算逻辑、需要传入参数的内容设计为方法，划分逻辑非常清晰，并不是随意设定的。

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