We could call this "passing references to objects by value."
But in any case, that's the point that made me go wtf while reading through as well. Whatever you want to call it, it's the same as what C (when not passing pointers), Java, PHP, Javascript, and many many other languages use.
Which is why it's so frustrating we don't have a good, easily-understood/well-known name for it.
An entry in a Python dictionary that is the namespace for the current scope.
For example, to repeat a response I gave to someone else upthread, compare a variable assignment in C and Python.
In C:
int i = 17;
In Python:
i = 17
Set aside one pointer's worth of storage on the heap, yes; not on the stack or in the program's data segment, which is what the C statement I gave does.
> and fill it with the bit pattern for the pointer pointing to the value 17 (which you may have to create first)"
Which has no analogue whatever in the C version.
Also, you completely left out the part about creating an entry in the namespace dictionary, which also has no analogue whatever in the C version, and which involves additional memory allocations.
Except for locals. (Well, OK, the Python stack is reified in the heap, but local variables are translated into small integer indices into the stack frame.)
> an entry in the namespace dictionary
Except for locals, which do not involve memory allocations or dictionary lookups.
Anyway, we're getting farther and farther away from the topic, which was that Python argument passing is no different from any other language in which everything is an object.
I meant the C stack, not the Python stack. At the C level all Python objects are allocated on the heap (except for some of the singletons like None which are statically allocated by the interpreter). (The fact that I used the term "heap" indicates that I was talking about the C level, since there is no "heap" at the Python level.)
> Python argument passing is no different from any other language in which everything is an object.
I disagree, since again you have left out the namespace binding step completely.
Can you explain the difference? What is a "namespace binding"? When accessing a variable's value, the interpreter's code sure looks like it treats the variable name as the name of a storage location.
> Passing a variable to a function means passing a particular namespace binding
"Passing a variable to a function" is not a thing. Passing a value to a function means passing a pointer to that value. This is the same for "foo(some_var)" and "foo(1)". Since "1" is presumably not a "namespace binding", you seem to suggest that there are different parameter passing mechanisms for these cases. There aren't.