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
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.