In addition python also does have arrays if you want/need them: https://docs.python.org/3.7/library/array.html
The distinction between passing the value of a reference being used by the caller and passing a reference to the caller's stack is so rarely important or useful that there's no consensus terminology for it. The distinction that's actually relevant and useful is whether, when we write f(a), f receives the (thing we would call the) value of a or a reference to the value of a (and in particular whether f can change the value of a). In Python, f can change the value of a (that is to say, the thing Python programmers understand to be the value of a); therefore Python is pass by reference as the term is usually understood (and certainly any term for its call style that uses "value" is more misleading than calling it "pass by reference").
And the reason for that is essentially all modern languages make copies of something when passing argument parameters. The only question is what they are passing and exactly how hard the language layer works to make it look as if you are or are not passing something by reference.
I have to reach to something as obscure as Forth to find a language that does not work that way, and truly does not copy parameters into a function. (I haven't dug into Factor enough to know if under the hood it still copies parameters.) It's a very unusual choice to not copy something for a function call.
(This is one of the ways our CPUs have been optimized for the languages we run; they make this intuitively expensive operation otherwise cheaper than it would be on a naively designed CPU.)
Then of course someone turns on whole program optimization for C++, half the code gets inlined into one terrifying large function, nothing is copied anywhere, and the code runs 2x faster.
Then some poor SOB has to debug the assembly code for all of this and has nightmares for years after.
Not like I'd know or anything. :)`
> In Python, f can change the value of a
but it can't. `f` can't change the object which `a` references:
def f(x): x = 5
is a function with no visible effect. When called as `f(a)`, `a` retains whatever value it had previously.People who believe Python is "call-by-reference" don't understand this and write incorrect or overcomplicated code as a consequence. The distinction is important.
There is no consensus that "pass by reference" denotes that, whatever a wikipedia editor says. Normal working programmers do not understand "pass by reference" to mean specifically "pass a reference to the caller's stack" but only the more general concept of "pass a reference to the value of a". If you want to talk specifically about what kind of reference gets passed, you need some new terms for that, and both the new terms you come up with will be subtypes of what most of the world will continue to understand as a general category of "pass by reference". No-one outside of these arguments on HN gets confused about whether you can write a swap function in Python; people understand "pass by reference" to mean something more general and entirely true of Python (and Java and so on). You can tell by how often we see those languages described as "pass by reference".
> but it can't. `f` can't change the object which `a` references:
Yes it can. It can't make a to refer to a different object (as your f tries to), but it can change the object a refers to just fine.
I might be misunderstanding you, but I don't think you can do this in C++. References can't be changed to point to a different object after initialization. If you have code like:
void MyFunc(Foo& ref_param) {
Foo new_foo;
ref_param = new_foo;
}
The assignment above isn't "changing the value to which a caller's variable is bound". Instead, it's running the '=' operator on the Foo object to copy the state from new_foo to ref_param. To demonstrate this, you could run the following to see that the addresses are the same: Foo original_object;
Foo& object_ref = original_object;
MyFunc(object_ref);
// object_ref still points to the same address
assert(&original_object == &object_ref);
Under the hood, C++ reference params are basically syntactic sugar for passing by pointer-value, so this behavior isn't surprising.This is a well-known distinction that goes by several names, see e.g. https://en.m.wikipedia.org/wiki/Evaluation_strategy#Call_by_...
No, Python doesn't even do that, because Python variables aren't names for storage locations to begin with. They're namespace bindings. Passing a variable to a Python function means transferring a namespace binding from the caller's namespace to the function's local namespace.
In C:
int i = 17;
Means "set aside one int's worth of storage and fill it with the bit pattern for the number 17".In Python:
i = 17
means "create an int object with the value 17 and bind it in the current namespace dictionary to the name i".More abstractly, Historically, in computing "list" connotes pointers and "array" connotes sequential memory. The connotations imply engineering tradeoffs. [1] "List" may make more sense for a beginning programmer. It is an arbitrary context switch for programmers writing in multiple languages. Considering that one of the driving use cases of Python has been systems programming, "list" is misleading regarding performance characteristics. [2]
[1]: For example as in Scala https://docs.scala-lang.org/overviews/collections/performanc...
[2]: googling "python arrays" returns a lot of results explaining the difference between Python's Arrays and Python's Lists. "List" is "foo => spam" and "bar => eggs" Pythonism gone too far.
In Python, Arrays are sequence types and behave very much like lists[1] In other words, even in Python, arrays have similar semantics to Javascript Arrays not Java Arrays.
What Java, JavaScript and C# call "arrays"
are each very much like what Python calls
"lists'.
In Java and C#, 'arrays' are fixed size at creation time.Both Java and C# provide 'lists' which are variable sized*
Python 'lists' are variable-sized.
Seems like a consistent naming scheme to me?
*there might be an underlying array that gets reallocated - but it's encapsulated within the list object; the reference to the list object is unchanged when this happens.
But Python predates C# and Java.
The difference between "pass by value" and "pass by reference" for reference variables is how the variables themselves are handled. For example, if you pass a reference "by reference" to a function and set it to null, then the reference variable in the calling code is also set to null and will cause null ref exception if you try to access the object. Whereas if you pass a reference "by value", if you set the variable to null, the calling code variable isn't affected.
Pass by value and pass by reference is not about objects or types really, it's about variables.
this will not change the array which was passed in and is a purely local change in C#.
static void Change(ref int[] myArray) on the other side would change the array which was passed in.
However, if you reassigned your copy of a pointer in the body of a function, the original pointer would still point to the same place it did before the function was called.
That's not the same thing as actual pass-by-reference in languages like C++.
The biggest irony here is that if you wrote your code in C instead, you would actually pass more arguments by reference than in equivalent python, because you're going to use pointers for everything but primitive integer values.
To the author:
1. Java, JavaScript and C# all have types which are passed by reference. (They also have types which are passed by value.)
2. Python lists are not arrays, if by arrays you mean a C- or FORTRAN-style block of non-resizable memory which is indexed by position. Python lists are much more like the Java List or C# IList interface.