On Mon, Apr 7, 2008 at 9:00 PM, Alexander Belopolsky <
report@bugs.python.org> wrote:
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.