Message 65100 - Python tracker (original) (raw)
On Mon, Apr 7, 2008 at 9:00 PM, Alexander Belopolsky <report@bugs.python.org> wrote:
Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment:
Thomas,
Could you add BUILD_*UNPACK opcodes documentation to Doc/library/dis.rst? It would also help if you modify CALL_FUNCTION* opcodes' documentation to explain how they will interact with unpacking opcodes.
They don't interact. They're separate opcodes. The CALL_FUNCTION_* opcodes are almost untouched, except the _VAR and _VAR_KW versions: previously, they expected, on the stack, positional arguments followed by keyword/argument pairs followed by the *args sequence followed by the *kwargs mapping (for VAR_KW.) I just changed the order so *args is before the keyword/argument pairs. The change is not related to the BUILD*_UNPACK opcodes, but rather to Guido's request that the order of keyword arguments and args in the functioncall syntax changes. For the order of execution to remain sane, the arguments need to be pushed on the stack in that order, and keeping the _VAR opcode order the same would mean a large amount of ROT_ opcodes ;-P
Updating the docs is on the TODO list.
Do I understand correctly that non-starred arguments are packed into intermediate tuples/sets in the presence of starred arguments so that {a,b,c,d,e} is equivalent to {{a,b},c,{d,e}}? This should not be a problem for tuples, but with sets, it means that {a,b,c} may behave subtly differently from {a,*(b,c)}.
Yes, that's what happens, but only in the presence of *args. For functioncalls, it only happens to everything after the first *args (inclusive.) That means '{a, b, c}' does not change, and neither does 'func(a, b, c)' or 'func(a, b, *c)'. As for sets, I don't see why this would be a problem; there is no difference in the set created by {a, b, c} and the set created by {a, *{b, c}} or {a, *(b, c)}. The arguments are all evaluated in the same order (left to right), and c replaces b, b replaces a if they are considered equal by sets.