Why can flipping a tuple assignment change its behavior?

Question

There I was, all this time, under the impression that a, b, c = c, a, b is the same as a, c, b = c, b, a... I thought this was a way to assign variables at the same time so you don't have to create a bunch of temp vars. But apparently they're different because one breaks my code.

Here's my original/working implementation:

class Node:
    def __init__(self, v = None, next = None):
        self.v = v
        self.next = next
    def __repr__(self):
        return "Node(v=%r, nextV=%r)" % (self.v, self.next.v if self.next else None)

a = Node(1)
b = Node(2)
a.next = b

def flip(nodeA, nodeB):
    nodeB, nodeA.next, nodeA = nodeA, nodeB, nodeA.next
    return (nodeA, nodeB)

a, b = flip(a, b)
print "A=%r; B=%r" % (a, b)

Its correct/intended behavior is to swap the two nodes in a linked list, as shown by the output below:

A=Node(v=2, nextV=None); B=Node(v=1, nextV=2)

However, if I reorder the flip function like so:

def flip(nodeA, nodeB):
    nodeB, nodeA, nodeA.next = nodeA, nodeA.next, nodeB
    return (nodeA, nodeB)

...that output is broken:

A=Node(v=2, nextV=2); B=Node(v=1, nextV=2)

Node A ended up with a pointer back to itself (its nextV and v are identical), so an attempt to follow this tree would recurse forever.

Why aren't these results identical? Shouldn't tuple unpacking behave as if all assignments happened simultaneously?

Answer 1

Because one of the items you're modifying is an attribute of another, these aren't independent of each other -- a serialization order is needed to determine what the operation will do, and that operation is left-to-right.

Let's look at how that plays out, by writing this code as it would be with temporary variables.

---

Given the following shared prelude:

old_nodeA      = nodeA
old_nodeB      = nodeB
old_nodeA_next = nodeA.next

The working code is akin to the following:

# nodeB, nodeA.next, nodeA = nodeA, nodeB, nodeA.next

nodeB      = old_nodeA
nodeA.next = old_nodeB       # nodeA is still the same as old_nodeA here
nodeA      = old_nodeA_next

Here's the broken one:

# nodeB, nodeA, nodeA.next = nodeA, nodeA.next, nodeB

nodeB      = old_nodeA
nodeA      = old_nodeA_next
nodeA.next = old_nodeB       # we're changing old_nodeA_next.next, not old_nodeA.next

The difference is that nodeA.next refers to the next attribute of a different nodeA between the two cases.

---

Let's look at how this works out at runtime in the case where everything works right, with some pseudocode showing object IDs so you can distinguish between objects being mutated in-place vs having references changed:

# Working implementation
###############################################################
# id(nodeA) # id(nodeB) # AAA.v # AAA.next # BBB.v # BBB.next # 
###############################################################
# AAA       # BBB       # 1     # BBB      # 2     # None     # Starting condition
# AAA       # AAA       # 1     # BBB      # 2     # None     # nodeB = old_nodeA
# AAA       # AAA       # 1     # BBB      # 2     # None     # nodeA.next = old_nodeB
# BBB       # AAA       # 1     # BBB      # 2     # None     # nodeA = old_nodeA_next

In the working scenario, we switched A and B's names to each refer to the opposite node; nothing else changed.

By contrast:

# Broken implementation
###############################################################
# id(nodeA) # id(nodeB) # AAA.v # AAA.next # BBB.v # BBB.next # 
###############################################################
# AAA       # BBB       # 1     # BBB      # 2     # None     # Starting condition
# AAA       # AAA       # 1     # BBB      # 2     # None     # nodeB = old_nodeA
# BBB       # AAA       # 1     # BBB      # 2     # None     # nodeA = old_nodeA_next
# BBB       # AAA       # 1     # BBB      # 2     # BBB      # nodeA.next = old_nodeB

When we got to nodeA.next = old_nodeB, the name nodeA had already been assigned the id originally associated with node B (BBB in our example), so we changed the original node B's next pointer to point to itself, generating the loop at the core of the problem.