Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #95884 > unrolled thread

Re: packing unpacking depends on order.

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: packing unpacking depends on order. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-02 12:06 -0600
    Re: packing unpacking depends on order. Steven D'Aprano <steve@pearwood.info> - 2015-09-03 11:45 +1000
      Re: packing unpacking depends on order. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-02 21:32 -0600

#95884 — Re: packing unpacking depends on order.

On Wed, Sep 2, 2015 at 11:42 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 9/2/2015 6:01 AM, Antoon Pardon wrote:
>>
>>
>>>>> a = [1, 2, 3, 4, 5]
>>>>> b = 1
>>>>> b, a[b] = a[b], b
>>>>> a
>>
>> [1, 2, 1, 4, 5]
>>>>>
>>>>> a = [1, 2, 3, 4, 5]
>>>>> b = 1
>>>>> a[b], b = b, a[b]
>>>>> a
>>
>> [1, 1, 3, 4, 5]
>>
>> I think I understand how it gets these results
>> but I'm not really happy with them. I think python
>> should give the second result in both cases.
>
>
> I do not want the choice taken away from me.

I do. I think the former behavior is surprising, and that relying on
it would result in confusing, hard-to-read code. If you really want
the former, you can easily reproduce it with:

temp = a[b]
b, a[temp] = temp, b

[toc] | [next] | [standalone]

#95915

On Thu, 3 Sep 2015 04:06 am, Ian Kelly wrote:

> On Wed, Sep 2, 2015 at 11:42 AM, Terry Reedy <tjreedy@udel.edu> wrote:
>> On 9/2/2015 6:01 AM, Antoon Pardon wrote:
>>>
>>>
>>>>>> a = [1, 2, 3, 4, 5]
>>>>>> b = 1
>>>>>> b, a[b] = a[b], b
>>>>>> a
>>>
>>> [1, 2, 1, 4, 5]

[...]

> I do. I think the former behavior is surprising, and that relying on
> it would result in confusing, hard-to-read code. If you really want
> the former, you can easily reproduce it with:

Of course it's confusing, but the alternative is even more confusing.

b, a[b] = 1, 2

currently has simple, predictable semantics: evaluate the right hand side
from left to right, then assign to the left hand side bindings from left to
right. The order of assignments does not depend on where the right hand
side values come from, or whether a or b already exist. This will work
fine:

assert "a" not in locals() and "b" not in locals()
b, a, a[b] = 1, "CORD".split(), "A"


What's the alternative? I asked this question earlier, and got no answer --
apparently at least three people prefer behaviour that they cannot explain
how to get the results they want :-)

As far as I am concerned, having both of these:

    b, a[b] = a[b], b
    a[b], b = b, a[b]

result in the same bindings is not only hard to implement, but hard to
explain and hard to think about. Try to write an algorithm that gives the
result you want, one which supports all the cases including the case where
one or both of a and b don't exist prior to the assignments.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#95917

On Sep 2, 2015 7:51 PM, "Steven D'Aprano" <steve@pearwood.info> wrote:
>
> What's the alternative? I asked this question earlier, and got no answer --
> apparently at least three people prefer behaviour that they cannot explain
> how to get the results they want :-)
>
> As far as I am concerned, having both of these:
>
>     b, a[b] = a[b], b
>     a[b], b = b, a[b]
>
> result in the same bindings is not only hard to implement, but hard to
> explain and hard to think about. Try to write an algorithm that gives the
> result you want,

I don't think it's really all that difficult.

1) Evaluate the RHS from left to right as is already done, collecting
the values to be assigned.

2) Evaluate the LHS from left to right. Note there are only three
different types of assignments: assignments to names, assignments to
attributes (i.e. using __setattr__), and assignments to items (i.e.
using __setitem__).

a) For assignments to names, there is nothing to evaluate.

b) For assignments to attributes, the expression to the left of the .
must be evaluated and stored.

c) For assignments to items, the expression before the square brackets
and the expression inside the square brackets must be evaluated
(probably in that order, although it doesn't much matter as long as
it's consistent) and stored.

3) Perform the assignments, again from left to right.

There can still be ordering effects, e.g. if you do a, b.c = d, e and
b's __setattr__ references a, or if one of the expressions has side
effects. The same is also true on the RHS, as it is today. I'm not
really concerned with that possibility.

> one which supports all the cases including the case where
> one or both of a and b don't exist prior to the assignments.

That's a red herring. If either a or b don't exist prior to the
assignments, then the result of assigning to a[b] *should* be an
error.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web