I don't think that's true, as the function will never be able to change the binding, and only gets a reference to the value of the binding. If the function was passed a particular namespace binding, it would be able to change this binding's value, and that's not possible.
I agree that "pass by reference" is a misleading way to describe Python functions.
More precisely, the function's arguments when it is called are a set of values for variables taken from the caller's namespace, which then get bound to the corresponding names in the local namespace. You're right that "passing the binding" doesn't really describe that process very well.
Again, this is very obviously false, since a call need not involve any variables at all:
foo(1, 2, "three")
You are mistaken, and your talk of namespace bindings is just obfuscation. Python arguments are passed by pointer. Python namespaces bind names to pointers. There is no "binding" object passed in a function call.
True, in which case the values would just be constants. But they will still get bound to names in the function's local namespace.
> You are mistaken
No, I left out a case which, it seemed to me, did not affect the main point I was making. If you want to make clear that that's a possible case, fine, you've done so. But you haven't refuted (or even engaged with) my main point at all.
> your talk of namespace bindings is just obfuscation
No, it's a very important difference between what Python variables mean and what variables in language like C mean. You might think the difference is unimportant, but not everyone agrees with you.
> Python arguments are passed by pointer. Python namespaces bind names to pointers.
At the C level inside the interpreter, yes, this is true: every "object", such as the 1, 2, and "three" in your example, is a pointer to a C struct containing the object's data (sometimes including further pointers). Again, that doesn't affect my main point at all.
> There is no "binding" object passed in a function call.
I already agreed to this in my response to pstch upthread (the post of mine you originally replied to). Once more, it doesn't affect my main point at all.
OK. Your main point (now that you have shifted the goalposts) seems to be that argument passing induces a binding of the parameter name to the argument value, yes?
In the abstract, this point is meaningless since it applies equally to every other programming language. In this C function:
void foo(int x, float y, char *z) { ... }
In the concrete, the point is also meaningless since those bindings do not involve dictionaries as you seem to think. For positional functional arguments, loooong before the call takes place, the bytecode compiler resolves names to stack indices, and the variables are accessed through those. Just like C can access arguments passed on the stack using constant offsets from the stack pointer.
Here is the code for the normal call fast path: https://github.com/python/cpython/blob/62be74290aca26d16f3f5...
f = _PyFrame_New_NoTrack(tstate, co, globals, NULL);
if (f == NULL) {
return NULL;
}
fastlocals = f->f_localsplus;
for (i = 0; i < nargs; i++) {
Py_INCREF(*args);
fastlocals[i] = *args++;
}
result = PyEval_EvalFrameEx(f,0);
Access to these arguments inside the callee is via the LOAD_FAST bytecode instruction: https://github.com/python/cpython/blob/master/Python/ceval.c...
case TARGET(LOAD_FAST): {
PyObject *value = GETLOCAL(oparg);
...
#define GETLOCAL(i) (fastlocals[i])
I'm done with this thread now.
It's that there is an extra step involved that does not occur in languages like C.
> those bindings do not involve dictionaries as you seem to think
For positional arguments, you are correct. But, as you note, there is still an extra memory allocation on the heap, because the stack at the Python level uses heap memory, not stack memory, at the C level.
For keyword arguments, as you agree, there is a dictionary entry created.
> Local variables are exactly what you claimed they were not
More precisely, local variables inside a function that correspond to positional arguments are, for performance reasons, stored in an array of function local pointers at the C level, instead of being stored as dictionary entries (namespace bindings).
But the fact that this is a particular exception to Python's normal treatment of variables simply highlights the point I was making.