Created on 2017-04-15 17:27 by serhiy.storchaka, last changed 2017-04-18 12:35 by ncoghlan.
|msg291725 - (view)||Author: Serhiy Storchaka (serhiy.storchaka) *||Date: 2017-04-15 17:27|
Two new opcodes BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL (added in 3.5 and 3.6) have too long names (26 and 28 characters). This exceeds the width of the opcode names in the dis module (20 characters). Increasing the width of the column will make opcode arguments too distant from opcode names, that will decrease readability. The better solution would be renaming these two opcodes. They are used for merging iterables and mappings of positional and keyword arguments when used var-positional (*args) and var-keyword (**kwargs) arguments. Maybe new names should reflect this. >>> dis.dis('f(a, b, *args, x=x, y=y, **kw)') 1 0 LOAD_NAME 0 (f) 2 LOAD_NAME 1 (a) 4 LOAD_NAME 2 (b) 6 BUILD_TUPLE 2 8 LOAD_NAME 3 (args) 10 BUILD_TUPLE_UNPACK_WITH_CALL 2 12 LOAD_NAME 4 (x) 14 LOAD_NAME 5 (y) 16 LOAD_CONST 0 (('x', 'y')) 18 BUILD_CONST_KEY_MAP 2 20 LOAD_NAME 6 (kw) 22 BUILD_MAP_UNPACK_WITH_CALL 2 24 CALL_FUNCTION_EX 1 26 RETURN_VALUE
|msg291778 - (view)||Author: Nick Coghlan (ncoghlan) *||Date: 2017-04-17 04:32|
If we used the names from inspect.Parameter.kind (https://docs.python.org/3/library/inspect.html#inspect.Parameter.kind) these would become: * BUILD_VAR_POSITIONAL * BUILD_VAR_KEYWORD which would be 20 and 17 letters long, respectively. I think that would also make the disassembled bytecode more self-explanatory: >>> dis.dis('f(a, b, *args, x=x, y=y, **kw)') 1 0 LOAD_NAME 0 (f) 2 LOAD_NAME 1 (a) 4 LOAD_NAME 2 (b) 6 BUILD_TUPLE 2 8 LOAD_NAME 3 (args) 10 BUILD_VAR_POSITIONAL 2 12 LOAD_NAME 4 (x) 14 LOAD_NAME 5 (y) 16 LOAD_CONST 0 (('x', 'y')) 18 BUILD_CONST_KEY_MAP 2 20 LOAD_NAME 6 (kw) 22 BUILD_VAR_KEYWORD 2 24 CALL_FUNCTION_EX 1 26 RETURN_VALUE
|msg291792 - (view)||Author: Serhiy Storchaka (serhiy.storchaka) *||Date: 2017-04-17 09:15|
I like the names BUILD_VAR_POSITIONAL and BUILD_VAR_KEYWORD. The downside is that this breaks relations between them and very similar opcodes BUILD_TUPLE_UNPACK and BUILD_MAP_UNPACK. The only differences between BUILD_*_UNPACK and BUILD_*_UNPACK_WITH_CALL opcodes is that the latter takes a function name from the stack for error message and BUILD_MAP_UNPACK_WITH_CALL doesn't allow key duplications in contrary to BUILD_MAP_UNPACK. But the names BUILD_TUPLE_UNPACK and BUILD_MAP_UNPACK doesn't look very good too.
|msg291832 - (view)||Author: Nick Coghlan (ncoghlan) *||Date: 2017-04-18 12:35|
I think it should be sufficient connection to describe the link in the documentation as: * BUILD_VAR_POSITIONAL: a variant of BUILD_TUPLE_UNPACK tailored specifically for use in function calls * BUILD_VAR_KEYWORD: a variant of BUILD_MAP_UNPACK tailored specifically for use in function calls The BUILD_*_UNPACK documentation could also point to their relevant function call counterpart: "Note: function calls do not use this opcode, they use the specialized BUILD_VAR_<kind>".
|2017-04-18 12:35:37||ncoghlan||set||messages: + msg291832|
|2017-04-17 09:15:31||serhiy.storchaka||set||messages: + msg291792|
|2017-04-17 08:44:07||Jim Fasarakis-Hilliard||set||nosy:
+ Jim Fasarakis-Hilliard|
|2017-04-17 04:32:28||ncoghlan||set||messages: + msg291778|