No idea why you think it seems that way. Using a temporary variable is not "just sugar", it's a big change in semantics! Take a more familiar example: x,

No idea why you think it seems that way. Using a temporary variable is not "just sugar", it's a big change in semantics! Take a more familiar example: x, y = (y, x) Let's pretend that this is "just sugar" for using a temporary variable. What would the desugared version look like? As a first guess, how about: z = (y, x) x = z[0] y = z[1] del(z) This seems fine, but it's wrong. For example, it would break the following code (since `z` would get clobbered): z = "hello world" x, y = (y, x) print(z) A temporary variable would need to be "fresh" (i.e. not clobber any existing variable). As far as I'm aware, there's no syntax for that in Python. What we can do is create a fresh scope, so that the temporary variable would merely shadow an existing binding rather than overwrite it. We can do that with a lambda and the new `:=` syntax: (lambda z: (x := z[0], y := z[1]))((y, x)) However, this alters the semantics because the stack will be different. For example, we might have a class which forbids some attribute from being altered: class A(object): def __init__(self, x): super(A, self).__setattr__('x', x) def __setattr__(self, name, value): if name == "x": raise Exception("Don't override 'x'") return super(A, self).__setattr__(name, value) This will raise an exception if we try to swap two attributes: >>> a = A('foo') >>> a.y = 'bar' >>> print(repr({'x': a.x, 'y': a.y})) {'y': 'bar', 'x': 'foo'} >>> a.x, a.y = (a.y, a.x) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 6, in __setattr__ Exception: Don't override 'x' If we replace this with the lambda version above, the exception will have a different stack trace, which we can catch and process in arbitrary ways. For example, maybe we know that the `foo` function will trigger these exceptions when given `A` objects, but it's a recoverable error. So we "ask for forgiveness instead of permission" by catching these exceptions somewhere, looking checking the stack trace to see if the Nth stack frame is `foo`, and abort if it wasn't. If we "desugared" using the above lambda, the Nth stack frame source of the exception would be a different function (`<lambda>` instead of `foo`) and hence such a program would abort. On the one hand, that's a pretty crappy program. But on the other it demonstrates that "use a temporary variable" is not "easy" in the general case (which is what language implementations must handle).