詳解增強算術賦值：“-=”操作是怎么實現(xiàn)的？

序言

本文是 Python語法糖 系列文章之一。最新的源代碼可以在 desugar 項目中找到（https://github.com/brettcannon/desugar）。

介紹

Python 有一種叫做增強算術賦值（augmented arithmetic assignment）的東西。可能你不熟悉這個叫法，其實就是在做數(shù)學運算的同時進行賦值，例如 a -= b 就是減法的增強算術賦值。

增強賦值是在 Python 2.0 版本中 加入進來的。（譯注：在 PEP-203 中引入）

剖析 -=

因為 Python 不允許覆蓋式賦值，所以相比其它有特殊/魔術方法的操作，它實現(xiàn)增強賦值的方式可能跟你想象的不完全一樣。

首先，要知道a -= b在語義上與 a = a-b 相同。但也要意識到，如果你預先知道要將一個對象賦給一個變量名，相比a - b 的盲操作，就可能會更高效。

例如，最起碼的好處是可以避免創(chuàng)建一個新對象：如果可以就地修改一個對象，那么返回 self，就比重新構造一個新對象要高效。

因此，Python 提供了一個__isub__() 方法。如果它被定義在賦值操作的左側（通常稱為 lvalue），則會調用右側的值（通常稱為 rvalue ）。所以對于a -= b ，就會嘗試去調用 a.__isub__(b)。

如果調用的結果是 NotImplemented，或者根本不存在結果，那么 Python 會退回到常規(guī)的二元算術運算：a - b。（譯注：作者關于二元運算的文章，譯文在此）

最終無論用了哪種方法，返回值都會被賦值給 a。

下面是簡單的偽代碼，a -= b 被分解成：

#?實現(xiàn)?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

歸納這些方法

由于我們已經實現(xiàn)了二元算術運算，因此歸納增強算術運算并不太復雜。

通過傳入二元算術運算函數(shù)，并做一些自省（以及處理可能發(fā)生的 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__)，且可以推斷出其它內容：函數(shù)名、調用什么 __i*__ 函數(shù)，以及當二元算術運算出問題時，該調用哪個可調用對象。

我發(fā)現(xiàn)幾乎沒有人使用**=

在寫本文的代碼時，我碰上了 **= 的一個奇怪的測試錯誤。在所有確保 __pow__ 會被適當?shù)卣{用的測試中，有個測試用例對于 Python 標準庫中的operator 模塊卻是失敗。

我的代碼通常沒問題，如果代碼與 CPython 的代碼之間存在差異，通常會意味著是我哪里出錯了。

但是，無論我多么仔細地排查代碼，我都無法定位出為什么我的測試會通過，而標準庫則失敗。

我決定深入地了解 CPython 內部發(fā)生了什么。從反匯編字節(jié)碼開始：

>>>?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 循環(huán)中的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個月前，這個問題被部分地發(fā)現(xiàn)，并提交了 bug。我修復了該問題，并在 python-dev 上作了說明。

截至目前，這似乎會在 Python 3.10 中修復，我們還需要在 3.8 和 3.9 的文檔中添加關于 **= 有 bug 的通知（該問題可能很早就有了，但較舊的 Python 版本已處于僅安全維護模式，因此文檔不會變更）。

修復的代碼很可能不會被移植，因為它是語義上的變化，并且很難判斷是否有人意外地依賴了有問題的語義。但是這個問題花了很長時間才被注意到，這就表明 **= 的使用并不廣泛，否則問題早就被發(fā)現(xiàn)了。