PEP 572使用语法y := f(x)定义赋值表达式，（常规）赋值语句的主要区别在于它们是表达式。
这导致:=受到=的一些限制，而这些限制在PEP 572中列出。对我来说，这些限制都是合理的，除了...
不支持扩展分配：
total += tax # Equivalent: (total := total + tax)
从我所看到的，我想说的是，{+:= 2 的连贯性在任何地方{{ 1}}是允许的。而且我天真地以拒绝执行增强的赋值表达式为理由，因为它们在语言中的添加会带来高昂的实现成本（带来的好处很少）。
PEP 572本身给出了一个示例，其中使用了增强的赋值表达式：
出现在列表，集合或字典理解中或生成器表达式中的赋值表达式（以下统称为“理解”）将目标绑定到包含范围中，从而对该范围内的目标使用非本地或全局声明，如果存在。出于此规则的目的，嵌套理解的包含范围是包含最外层理解的范围。 Lambda视为包含作用域。
[...]
[这种特殊情况]允许一种紧凑的方式来从理解中更新可变状态，例如：
+=
但是，阅读频繁提出异议时，以下异议和相应答案似乎暗示着不实施增强赋值表达式是一种故意的选择，导致x := x + y更加灵活（在此情况下，方面）比# Compute partial sums in a list comprehension
total = 0
partial_sums = [total := total + v for v in values]
print("Total:", total)
：
With assignment expressions, why bother with assignment statements?
这两种形式具有不同的灵活性。
=运算符可以在较大的表达式内使用；:=语句可以扩充为:=及其朋友，可以链接，也可以分配给属性和下标。
因此，我的问题仍然存在：一旦=成为语言的一部分，是否有任何技术原因阻止将“ +=”添加到该语言？
1 ：我想出了语法“ +:=”，而扩展赋值表达式的实际语法可能有所不同（“ :=”？）；这不是这个问题的目的。
2 ：很显然，它也涵盖了+:=，:+=，...