该
for循环遵循标准的分配规则,因此适用于
for原始分配的LHS的内容应与以下各项一起使用:
使用分配的标准规则将每个项目依次分配到目标列表
该
for结构简单地调用了分配给目标的基本机制,在您的示例代码中,该机制为
STORE_SUBSCR:
>>> foo = [42]>>> k = {'c': 'd'}>>> dis.dis('for k["e"] in foo: pass') 10 SETUP_LOOP 16 (to 18) 2 LOAD_NAME 0 (foo) 4 GET_ITER >> 6 FOR_ITER 8 (to 16) 8 LOAD_NAME 1 (k) 10 LOAD_ConST 0 ('e') 12 STORE_SUBSCR <-------------------- 14 JUMP_ABSOLUTE 6 >> 16 POP_BLOCK >> 18 LOAD_ConST 1 (None) 20 RETURN_VALUE但是令我惊讶的是,这不是语法错误
显然,在常规任务中,任何有效的方法如下:
完整切片分配 :
>>> for [][:] in []:... pass... >>>
列表订阅
>>> for [2][0] in [42]:... pass... >>>
字典订阅等将是有效的候选目标,唯一的例外是 链接分配 ;但是,我暗中认为可以编写一些肮脏的语法来执行链接。
我希望仅单个标识符和标识符的元组
我想不出字典键作为目标的好用例。此外,在循环主体中进行字典键分配比在
for子句中将其用作目标更具可读性。
但是,在常规分配中非常有用的扩展解压缩(Python 3)在for循环中也同样方便:
>>> lst = [[1, '', '', 3], [3, '', '', 6]]>>> for x, *y, z in lst:... print(x,y,z)... 1 ['', ''] 33 ['', ''] 6
这里还召唤了分配给不同目标的相应机制。多个
STORE_NAMEs:
>>> dis.dis('for x, *y, z in lst: pass') 10 SETUP_LOOP 20 (to 22) 2 LOAD_NAME 0 (lst) 4 GET_ITER >> 6 FOR_ITER 12 (to 20) 8 EXTENDED_ARG 1 10 UNPACK_EX 257 12 STORE_NAME 1 (x) <----- 14 STORE_NAME 2 (y) <----- 16 STORE_NAME 3 (z) <----- 18 JUMP_ABSOLUTE 6 >> 20 POP_BLOCK >> 22 LOAD_ConST 0 (None) 24 RETURN_VALUE证明a
for是几乎不连续执行的赋值语句。



