> shove it back into variable a

Python is more of a lisp. The assignment semantics are different to C. Actually, you're letting the name "a" point to the newly created object.

In C, a variable is a memory position you can fill and point to.

In Python, a variable is a name that points to a memory position.

Other than in regard to the way type works, and lexical capture, mainstream Lisps have variable semantics that work more or less like C. The names of lexical variables disappear at compile time; a given a variable may be just a slot in some environment frame (perhaps a stack frame), a machine register, or disappear entirely via constant folding: or any of these three in different areas of the code. In any case, symbols do not "point" at memory positions.

Similarity to C is no accident here, since the lexical scoping concepts in Lisps like Scheme and CL, as well as in C, both trace back to Algol.

Classic Lisp global/dynamic variables may store a global value a "value cell" which is closely tied to the symbol itself (perhaps stored in it).

I would agree that the compilation to machine code might do something different than the high-level mental model. Though the machine code or intermediary code might be interesting to some, the semantics and mental model on a higher level are usually what we reason about. If we don't do it this way, then Lisp doesn't exist and functional programming doesn't exist, because we don't have a machine model that behaves like it.

And in that sense, C assignment and Lisp assignment are different beasts. Mainly in that - again in the semantics of the high-level description - "memory reservation" in C happens when we declare the left-hand side of an assignment and in Lisp it happens when we construct the right-hand side.

Though if you can show me a mainstream Lisp where the assignment works like setting a memory cell and not like a bind, I'm happy to be proven wrong.

If you follow the abstract mental model that the binding construct such as let reserves the memory cells, which assignment and initialization just fill in, you will not misunderstand your programs, except for some bugs that interact with optimization where you have to know when to let go of the model.

The right hand side reserves memory only in the sense that some heap object is allocated (if that is the case), but that is secondary to the assignment; and that is the same as C also, as in:

  f = fopen(...); // right hand allocates stream; pointer moves into variable.

> if you can show me a mainstream Lisp where the assignment works like setting a memory cell and not like a bind, I'm happy to be proven wrong.

The mainstream Lisps clearly separate binding from assignment.

   (let (x)        ;; x refers to a freshly allocated cell (nil-initialized, in Common Lisp)
     ...
     (setq x 42)   ;; cell is clobbered, replacing nil with 42.
     ...)

Some of the terminologly used in the specifications is a bit confused. For instance, Common Lisp says say that:

1. A variable is a "binding in the variable namespace" (Glossary)

2. A binding is an association between a name and a value (Glossary)

3. Yet, the description of SETQ uses language like: "First form1 is evaluated and the result is stored in the variable var1".

4. LET is described like this "let and let* create new variable bindings and execute a series of forms that use these bindings". No binding creation semantics is mentioned for SETQ.

Results can only be stored in storage places; nothing can be stored in an "association between a name and a value", unless that association is actually set up through a memory cell: the name refers to a location and the location holds a value. SETQ isn't described in terms of breaking an old binding and setting up a new one..

In the case of dynamic and global variables, there is a term "value cell" which the Glossary defines: like this: "The place which holds the value, if any, of the dynamic variable named by that symbol, and which is accessed by symbol-value. "

Let's turn our attention to Scheme. R7RS says in 3.1. Variables, syntactic keywords, and regions this:

"An identifier can name either a type of syntax or a location where a value can be stored."

and:

"An identifier that names a location is called a variable and is said to be bound to that location."

"The value stored in the location to which a variable is bound is called the variable’s value."

The next sentence is a kicker, and can be regarded as a criticism of the ANSI CL definition of binding:

"By abuse of terminology, the variable is sometimes said to name the value or to be bound to the value."

If you think that Lisp variables are bindings to values, then according to the Scheme maintainers, you've fallen victim to abuse of terminology. :)

I would read that as not implementing `__iadd__` https://docs.python.org/3/reference/datamodel.html#object.__...

Ah I got it. So it would fallback to __add__ if __iadd__ doesn't exist.

Thanks!

Tuples don't have an in-place addition method (__iadd__), and if the left operand of += is a name that does not contain a value that supports __iadd__, then l += r is a fancy way of writing l = l + r.

But if l does support __iadd__, then l += r becomes l.__iadd__(r).

That's true though kind of an implementation detail. Conceptually x += y is always x = x.__iadd__(y), and x can have its own semantics for what iadd does. Conventionally that is that mutable objects modify themselves in place and return themselves, while immutable objects create a new object and return that.

This behavior for list and tuple is familiar from regular local variables. Together with the fact that obj.x = ... always means "create or rebind an instance variable" never "rebind the A.x class variable", I think the example is less surprising.