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 &lt;<a href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>&gt; 
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 &lt;<a href="mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]</a>&gt; added the comment:<br>
<br>
</div>Thomas,<br>
<br>
Could you add BUILD_*_UNPACK opcodes documentation to<br>
Doc/library/dis.rst? &nbsp; It would also help if you modify CALL_FUNCTION_*<br>
opcodes&#39; documentation to explain how they will interact with unpacking<br>
opcodes.</blockquote><div><br>They don&#39;t interact. They&#39;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&#39;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&#39;s what happens, but only in the presence of *args. For functioncalls, 
it only happens to everything after the first *args (inclusive.) That means 
&#39;{a, b, c}&#39; does not change, and neither does &#39;func(a, b, c)&#39; 
or &#39;func(a, b, *c)&#39;. As for sets, I don&#39;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)}.&nbsp; 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 &lt;<a href="mailto:[EMAIL 
PROTECTED]">[EMAIL PROTECTED]</a>&gt;<br><br>Hi! I&#39;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

Reply via email to