Thomas Wouters <[EMAIL PROTECTED]> added the comment:
On Mon, Apr 7, 2008 at 9:00 PM, Alexander Belopolsky <[EMAIL PROTECTED]>
wrote:
>
> Alexander Belopolsky <[EMAIL PROTECTED]> 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.
Added file: http://bugs.python.org/file9970/unnamed
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2292>
__________________________________<br><br><div class="gmail_quote">On Mon, Apr 7, 2008 at 9:00 PM, Alexander
Belopolsky <<a href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>>
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
Alexander Belopolsky <<a href="mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]</a>> added the comment:<br>
<br>
</div>Thomas,<br>
<br>
Could you add BUILD_*_UNPACK opcodes documentation to<br>
Doc/library/dis.rst? It would also help if you modify CALL_FUNCTION_*<br>
opcodes' documentation to explain how they will interact with unpacking<br>
opcodes.</blockquote><div><br>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<br>
<br>Updating the docs is on the TODO list.<br><br></div><blockquote
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin:
0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Do I understand correctly that non-starred arguments are packed into<br>
intermediate tuples/sets in the presence of starred arguments so that<br>
{a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a<br>
problem for tuples, but with sets, it means that {a,b,c} may behave<br>
subtly differently from {a,*(b,c)}.<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>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.<br>
</div></div><br>-- <br>Thomas Wouters <<a href="mailto:[EMAIL
PROTECTED]">[EMAIL PROTECTED]</a>><br><br>Hi! I'm a .signature virus!
copy me into your .signature file to help me spread!
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
