Isn't this by definition call by value? The reference / binding is passed by value. Changing the reference to point to something else will not make the other reference to point to the same too.
Call by value would mean that a copy of the value of the argument is passed to the function without involving the original value at all. To say the binding is passed by value is not useful, as all languages would then be considered "call by value", since _something_ needs to be passed into the function, and we can just call it a value.
This argument is as old as call-by-... definitions, but... What python holds in the variables are references to objects. Those are the values you're passing, so it's call by value using this reasoning.
Some languages do actually hold the value itself (struct for example) in the variable, so there you get a copy of the value (the struct contents). In python you get the copy of a reference (which again, is the value held in a variable).
Pedantically, sure, but I think the point is to explain it so that people actually understand. If you say "Python is call-by-value" to C programmer then they will probably have some serious misconceptions about what happens when you pass an object to a function.
> they will probably have some serious misconceptions about what happens when you pass an object to a function.
p = Person()
The thing on the left is object reference, the thing on the right is object. When you do some_func(p) or some_func(Person()), you don't pass an object but an object reference.
There. No serious misconceptions.
C# and Java are doing just fine having the same model and explaining it the same way. And C programmers just need to think of `p = Person()` as `Person *p = new_person()`
Well, yes, there might be. Because "object reference" sounds a lot like you're saying it's call-by-reference, and that's also confusing. it makes it sound like the output of this would be "overwritten":
def some_func(x): x = "overwritten"
p = Person()
some_func(p)
print p
In addition, my point was that using the term "call-by-value" is confusing, and since you didn't use that term in your explanation, it's all moot.
My point is writing a blog post saying python is neither call-by-value nor call-by-reference is made up shit and does nothing for someone who doesn't already understand it. Someone who doesn't already understand it will have to work through to get the gist of call-by-value and object references.
The blog post didn't simplify anything for someone who doesn't already understand it. So why not stick with terminology which is used by Java, C#, C among others?
>My point is writing a blog post saying python is neither call-by-value nor call-by-reference is made up shit
I guess so, in the sense that all of those terms are "made up shit". But they are useful for explaining the concepts.
>The blog post didn't simplify anything for someone who doesn't already understand it. So why not stick with terminology which is used by Java, C#, C among others?
Apparently, as others have pointed out here, the term "call-by-sharing" has largely come into popular use from people explaining how Python works in user groups. That's a strong indication that it actually is a pretty effective way to help newbies understand it.
I don't think they would be confused or get very many misconceptions, especially if they know how to mimic OOP in C. http://www.thejach.com/view/2010/1/oop_in_c_with_function_po... shows one way to do OOP in C (Zed's great C book shows another way for OOP that's prototypes-based like Javascript), one line of code is: `first_tank->fire_at(first_tank, second_tank);` Is it confusing that the second_tank object's health will decrease? Would they be confused over Python's `first_tank.fire_at(second_tank)`? In fact I think seeing that example of OOP would make another thing clear: the existence of 'self' in Python method arguments.
Additionally a C programmer has only ever heard of pass-by-value, so by introducing something new I'd think you would have a higher chance of confusing them. Now if you tell a C++ programmer that Python "isn't call-by-value", they'll immediately wonder how you can write a traditional swap() function (or more likely how to return-by-reference for efficiency), and you'll have to introduce them to new terminology like "call-by-shared-object", which it seems most people don't think is distinct from "call-by-object-pointer/'reference'-value" anyway.
Comments
Isn't this by definition call by value? The reference / binding is passed by value. Changing the reference to point to something else will not make the other reference to point to the same too.
Call by value would mean that a copy of the value of the argument is passed to the function without involving the original value at all. To say the binding is passed by value is not useful, as all languages would then be considered "call by value", since _something_ needs to be passed into the function, and we can just call it a value.
This argument is as old as call-by-... definitions, but... What python holds in the variables are references to objects. Those are the values you're passing, so it's call by value using this reasoning.
Some languages do actually hold the value itself (struct for example) in the variable, so there you get a copy of the value (the struct contents). In python you get the copy of a reference (which again, is the value held in a variable).
That is correct: the object reference is copied into the caller's symbol table when calling. Hence, CBV.
not true. the program can be compiled to directly reference the variables themselves
Pedantically, sure, but I think the point is to explain it so that people actually understand. If you say "Python is call-by-value" to C programmer then they will probably have some serious misconceptions about what happens when you pass an object to a function.
> they will probably have some serious misconceptions about what happens when you pass an object to a function.
The thing on the left is object reference, the thing on the right is object. When you do some_func(p) or some_func(Person()), you don't pass an object but an object reference.There. No serious misconceptions.
C# and Java are doing just fine having the same model and explaining it the same way. And C programmers just need to think of `p = Person()` as `Person *p = new_person()`
>There. No serious misconceptions.
Well, yes, there might be. Because "object reference" sounds a lot like you're saying it's call-by-reference, and that's also confusing. it makes it sound like the output of this would be "overwritten":
In addition, my point was that using the term "call-by-value" is confusing, and since you didn't use that term in your explanation, it's all moot.My point is writing a blog post saying python is neither call-by-value nor call-by-reference is made up shit and does nothing for someone who doesn't already understand it. Someone who doesn't already understand it will have to work through to get the gist of call-by-value and object references.
The blog post didn't simplify anything for someone who doesn't already understand it. So why not stick with terminology which is used by Java, C#, C among others?
>My point is writing a blog post saying python is neither call-by-value nor call-by-reference is made up shit
I guess so, in the sense that all of those terms are "made up shit". But they are useful for explaining the concepts.
>The blog post didn't simplify anything for someone who doesn't already understand it. So why not stick with terminology which is used by Java, C#, C among others?
Apparently, as others have pointed out here, the term "call-by-sharing" has largely come into popular use from people explaining how Python works in user groups. That's a strong indication that it actually is a pretty effective way to help newbies understand it.
I don't think they would be confused or get very many misconceptions, especially if they know how to mimic OOP in C. http://www.thejach.com/view/2010/1/oop_in_c_with_function_po... shows one way to do OOP in C (Zed's great C book shows another way for OOP that's prototypes-based like Javascript), one line of code is: `first_tank->fire_at(first_tank, second_tank);` Is it confusing that the second_tank object's health will decrease? Would they be confused over Python's `first_tank.fire_at(second_tank)`? In fact I think seeing that example of OOP would make another thing clear: the existence of 'self' in Python method arguments.
Additionally a C programmer has only ever heard of pass-by-value, so by introducing something new I'd think you would have a higher chance of confusing them. Now if you tell a C++ programmer that Python "isn't call-by-value", they'll immediately wonder how you can write a traditional swap() function (or more likely how to return-by-reference for efficiency), and you'll have to introduce them to new terminology like "call-by-shared-object", which it seems most people don't think is distinct from "call-by-object-pointer/'reference'-value" anyway.