介绍
Python 有一种叫做加强算术赋值（augmented arithmetic assignment）的货色。可能你不相熟这个叫法，其实就是在做数学运算的同时进行赋值，例如 a -= b 就是减法的加强算术赋值。
加强赋值是在 Python 2.0 版本中 退出进来的。（译注：在 PEP-203 中引入）
分析 -=
因为 Python 不容许笼罩式赋值，所以相比其它有非凡 / 魔术办法的操作，它实现加强赋值的形式可能跟你设想的不齐全一样。
首先，要晓得 a -= b 在语义上与 a = a-b 雷同。但也要意识到，如果你事后晓得要将一个对象赋给一个变量名，相比 a – b 的盲操作，就可能会更高效。
例如，最起码的益处是能够防止创立一个新对象：如果能够就地批改一个对象，那么返回 self，就比从新结构一个新对象要高效。
因而，Python 提供了一个__isub__() 办法。如果它被定义在赋值操作的左侧（通常称为 lvalue），则会调用右侧的值（通常称为 rvalue）。所以对于 a -= b，就会尝试去调用 a.__isub__(b)。
如果调用的后果是 NotImplemented，或者基本不存在后果，那么 Python 会退回到惯例的二元算术运算：a – b。
最终无论用了哪种办法，返回值都会被赋值给 a。
上面是简略的伪代码，a -= b 被分解成：
# 实现 a -= b 的伪代码
if hasattr(a, "__isub__"):
_value = a.__isub__(b)
if _value is not NotImplemented:
a = _value
else:
a = a - b
del _value
else:
a = a - b演绎这些办法
因为咱们曾经实现了二元算术运算，因而演绎加强算术运算并不太简单。
通过传入二元算术运算函数，并做一些自省（以及解决可能产生的 TypeError），它能够被丑陋地演绎成：
def _create_binary_inplace_op(binary_op: _BinaryOp) -> Callable[[Any, Any], Any]:
binary_operation_name = binary_op.__name__[2:-2]
method_name = f"__i{binary_operation_name}__"
operator = f"{binary_op._operator}="
def binary_inplace_op(lvalue: Any, rvalue: Any, /) -> Any:
lvalue_type = type(lvalue)
try:
method = debuiltins._mro_getattr(lvalue_type, method_name)
except AttributeError:
pass
else:
value = method(lvalue, rvalue)
if value is not NotImplemented:
return value
try:
return binary_op(lvalue, rvalue)
except TypeError as exc:
# If the TypeError is due to the binary arithmetic operator, suppress
# it so we can raise the appropriate one for the agumented assignment.
if exc._binary_op != binary_op._operator:
raise
raise TypeError(f"unsupported operand type(s) for {operator}: {lvalue_type!r} and {type(rvalue)!r}"
)
binary_inplace_op.__name__ = binary_inplace_op.__qualname__ = method_name
binary_inplace_op.__doc__ = (f"""Implement the augmented arithmetic assignment `a {operator} b`."""
)
return binary_inplace_op这使得定义的 -= 反对 create_binary_inplace_op(_ sub__)，且能够推断出其它内容：函数名、调用什么 i* 函数，以及当二元算术运算出问题时，该调用哪个可调用对象。
我发现简直没有人应用 =**
在写本文的代码时，我碰上了 **= 的一个奇怪的测试谬误。在所有确保 pow 会被适当地调用的测试中，有个测试用例对于 Python 规范库中的 operator 模块却是失败。
我的代码通常没问题，如果代码与 CPython 的代码之间存在差别，通常会意味着是我哪里出错了。
然而，无论我如许认真地排查代码，我都无奈定位出为什么我的测试会通过，而规范库则失败。
我决定深刻地理解 CPython 外部产生了什么。从反汇编字节码开始：
>>> def test(): a **= b
...
>>> import dis
>>> dis.dis(test)
1 0 LOAD_FAST 0 (a)
2 LOAD_GLOBAL 0 (b)
4 INPLACE_POWER
6 STORE_FAST 0 (a)
8 LOAD_CONST 0 (None)
10 RETURN_VALUE通过它，我找到了在 eval 循环中的 INPLACE_POWER：
case TARGET(INPLACE_POWER): {PyObject *exp = POP();
PyObject *base = TOP();
PyObject *res = PyNumber_InPlacePower(base, exp, Py_None);
Py_DECREF(base);
Py_DECREF(exp);
SET_TOP(res);
if (res == NULL)
goto error;
DISPATCH();}而后找到 PyNumber_InPlacePower()：
PyObject *
PyNumber_InPlacePower(PyObject *v, PyObject *w, PyObject *z)
{
if (v->ob_type->tp_as_number &&
v->ob_type->tp_as_number->nb_inplace_power != NULL) {return ternary_op(v, w, z, NB_SLOT(nb_inplace_power), "**=");
}
else {return ternary_op(v, w, z, NB_SLOT(nb_power), "**=");
}
}松了口气~ 代码显示如果定义了__ipow__，则会调用它，然而只在没有__ipow__ 时，才会调用__pow__。
然而，正确的做法应该是：如果调用__ipow__ 时出问题，返回了 NotImplemented 或者基本不存在返回，那么就应该调用 pow 和__rpow__。
换句话说，当存在__ipow__时，以上代码会意外地跳过 a**b 的后备语义！
实际上，大概 11 个月前，这个问题被局部地发现，并提交了 bug。我修复了该问题，并在 python-dev 上作了阐明。
截至目前，这仿佛会在 Python 3.10 中修复，咱们还须要在 3.8 和 3.9 的文档中增加对于 **= 有 bug 的告诉（该问题可能很早就有了，但较旧的 Python 版本已处于仅平安保护模式，因而文档不会变更）。
修复的代码很可能不会被移植，因为它是语义上的变动，并且很难判断是否有人意外地依赖了有问题的语义。然而这个问题花了很长时间才被留神到，这就表明 **= 的应用并不宽泛，否则问题早就被发现了。
以上就是本次分享的所有内容，想要理解更多 python 常识欢送返回公众号：Python 编程学习圈，发送“J”即可收费获取，每日干货分享