You should consider the following example:

>>> a = ‘x’
>>> b = lambda: a
>>> a = ‘y’
>>> b()
‘y’

Of course, but you could express this as well by using variables denoting locations, where locations are values that admit a disequality test. In the simple case where you only have locations to integers (or integer assignables), you would even define the equality test as a function of the language.

Maybe my question wasn’t clear: what is the downside with the existing technique of adding a new class of values, “locations”, that admit assignation/dereference operations, and using the existing binding constructs of the language to denote such values? Why do you prefer to introduce this (related) concept of “assignable” that is not a value, but not a variable either, and is manipulated through a specific binding construction?

I thought maybe that was favored by the choice of starting with stack-scoped assignables, that naturally follow a lexical binding discipline. Maybe you also find the binding construct (decl a := e in e) is more suggestive of the semantics of enlarging the store than a (ref e) primitive would be.

a = ['x']
if random.randint(0, 1) :
a = ['y']
else:
a = ['z']
print(a)

If each = was creating a brand new variable, then the second and third a above would be completely different variables, and thus the a in the last line could not be referring to both of them; it would at most refer to one or the other. But, of course, it does refer to both of them, because they are the same variable (or rather, assignable), the same as in the first line.

I suppose you could still cling to the claim “No, it’s still the case that there’s no re-assignment in Python. = creates new variables, always; it’s just that…” through some epicycles or another, but only through enough epicycles as to get this to behave exactly the same as if Python’s “variables” were assignables. Because they are.

But even in breaking old convention, there is value in agreeing on a new convention, and as “assignable” has already been chosen and used in at least one significant text, it might as well serve as the new convention to rally round.

It just happens to be the case that Python picked this silly syntax which makes declarations and re-assignments look the same (and then some stupid voodoo rules for when to parse ‘=’ as making a declaration of a new variable and when to parse it as re-assigning to an existing variable…). But underneath the superficial syntax, Python is just the same as any other typical imperative language in this respective.