为何使用海象运算符为类成员变量赋值会触发SyntaxError语法错误

这个限制不是语法实现的疏漏，是从海象运算符的设计阶段就刻意划定的使用边界，核心逻辑和原因可以拆解为几个部分：

海象运算符的设计定位 #

海象运算符（:=）的核心设计目的，是在表达式求值的同时，把结果值临时绑定到一个裸的标识符（也就是普通变量名）上，解决之前写Python时不得不把同一个值在两个地方重复书写的问题——比如先算一次值存到变量，再单独写一行if判断，中间多了一次冗余的代码。
它从一开始就不是要替代普通赋值语句的全部能力，当初的语法设计讨论里，就明确把海象的合法赋值目标限定为“简单命名的标识符”，不支持带复杂访问逻辑的目标。

禁止给属性赋值的具体原因 #

• 避免隐式副作用破坏代码可读性
  给对象属性赋值从来不是零成本操作：如果类定义了property装饰器的setter、或者自定义了__setattr__逻辑，给属性赋值会触发连带的后台逻辑——比如执行自定义的属性校验、联动更新其他关联属性。如果允许海象在if、while这类表达式上下文里悄悄完成属性赋值，读代码的人很可能只关注条件判断的逻辑，完全没意识到这行代码在背后修改了对象状态，甚至触发了复杂的业务流程，代码的可维护性会大幅下降。
  而普通的独立赋值语句（比如self.saved_eye = xxx）是摆在明面上的语句，大家看到就知道“这行在修改对象状态”，不会有认知偏差。
• 避免语法歧义带来的额外负担
  如果允许把属性访问（比如self.xxx）作为海象的赋值目标，会出现大量需要额外判断优先级的歧义场景。比如你写了一行代码if obj.attr := calc() > 10，其他读代码的人根本拿不准，这行到底是把calc() > 10的判断结果存到obj.attr，还是先把calc()的返回值存到obj.attr，再判断这个值是不是大于10。这类歧义不管是给解释器增加复杂的解析规则，还是给开发者增加读代码的心智负担，都完全得不偿失。
• 保持语法边界的一致性
  Python的普通赋值语句是“万能”的：左边可以是裸变量、对象属性、下标索引、甚至解包的多个目标。如果放开海象运算符支持属性赋值，那接下来就会有持续的需求问“为啥不能给下标赋值”“为啥不能解包赋值”，最终会让海象的使用规则越来越模糊。刻意把赋值目标限定为最简单的裸变量，反而让规则清晰易懂，没有模糊地带。

符合设计初衷的替代写法 #

你提到的用临时局部变量绕过报错，其实完全不是“凑出来的临时方案”，反而恰恰是海象运算符最适合的使用场景：

def ohyes(self):
    # 海象只负责把值临时绑定到局部变量，供后续判断和引用
    if saved_eye := self.eyes.index("left"):
        # 真正的属性赋值用独立的普通赋值语句，摆在明面上
        self.saved_eye = saved_eye
        print(self.saved_eye)

这种写法既保留了海象“减少重复代码”的优势，又把修改对象属性的动作变成了独立可见的语句，完全匹配它的设计定位。 #

内容的提问来源于stack exchange，提问作者Inyoung Kim 김인영