4 ms·

> Passing a variable to a function means passing a particular namespace binding from the caller's namespace to the function's local namespace. I don't think th

• pdonis 8y ago
  > the function will never be able to change the binding, and only gets a reference to the value of the binding 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.
  • tom_mellior 8y ago
    > the function's arguments when it is called are a set of values for variables taken from the caller's namespace Again, this is very obviously false, since a call need not involve any variables at all: foo(1, 2, "three") The function's arguments when it is called are a set of values taken from the caller, yes. And those values are obtained from evaluating expressions that may involve variables. But they might not. Saying that the values are "a set of values for variables taken from the caller's namespace" is wrong. 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.
    • pdonis 8y ago
      > this is very obviously false, since a call need not involve any variables at all 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.
      • tom_mellior 8y ago
        > But you haven't refuted (or even engaged with) 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) { ... } the C compiler also has to manage bindings from variable names to the locations where their values are stored. It needs that information to find the correct values in registers or (just like in Python) on the stack. 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/62be74290aca26d16f3f55ece7ff6dad14e60e8d/Objects/call.c#L274 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); This sets up a stack frame for the callee (on the heap, yes), then copies the arguments (which are pointers to PyObject) into slots in that stack frame numbered consecutively from 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#L1067 https://github.com/python/cpython/blob/master/Python/ceval.c... case TARGET(LOAD_FAST): { PyObject *value = GETLOCAL(oparg); ... which uses the GETLOCAL macro: https://github.com/python/cpython/blob/master/Python/ceval.c#L786 https://github.com/python/cpython/blob/master/Python/ceval.c... #define GETLOCAL(i) (fastlocals[i]) Nowhere are name-value bindings allocated dynamically in this normal case. Python does perform dictionary manipulation for keyword args, but not for positional ones. For normal positional arguments, the mechanism is exactly equivalent to a C (or whatever) compiler pushing arguments onto the stack. Local variables are exactly what you claimed that they were not, namely names for storage locations (stack slots). I'm done with this thread now.
        • 8y ago