There is an easy test to see if a language supports call-by-reference or not:

    a = 3
    b = 4
    swap(a,b)
    print a, b # 4 3

Edit: I hasten to add, the swap() function should be implemented "traditionally". i.e.:

    def swap(x, y):
      temp = x
      x = y
      y = temp

It's behaviorally call-by-value, where the value is always an object reference.

The difference is only mildly interesting, and the fervor with which you're arguing about it is wholly uninteresting, bordering on misleading. This is a semantic distinction with little to no use, and just serves to further confuse the rather simple and clear behavior.

it's not so terrible - it works well enough for c.l.p, and anyone used to call by value with references/pointers is capable of working things out themselves.

really, it's largely a python (and c.l.p) cultural thing. you're berating some guy who's just a messenger for something that, in its context, doesn't do any harm (indeed, might help some newbies) (i don't have any skin in this game, but the guys on c.l.p do great work helping others; if this helps them it's fine by me).

"Call-by-object-sharing" is better expressed as "call-by-object-pointer-value". But at this point it's just an argument over definitions. One either accepts that call-by-reference and call-by-value are the only two options along with the test above that includes C++, Ada, and Pascal as languages which support call-by-reference, or one doesn't.

I do not, there is also call by need and call by name. How does your test apply to Haskell? Incidentally call by sharing is much older than python. Wikipedia claims Liskov coined the term in 1974. I agree with you, call by value where the value happens to be a reference doesn't seem fundamentally different than call by value and probably doesn't need its own term.

http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sha...

Can Haskell pass the test? If it can't, it doesn't support call-by-reference.

You do bring up an interesting line of thought with call-by-need et al. I tend to just lump them under "lazy evaluation" and I don't really view them as impacting the value/reference dichotomy. The question there, then, is at the end of the day if/when an argument is evaluated (to whatever extent), does it match call-by-value or call-by-reference semantics? (And if the behavior is achieved with macro expansion, can it even rightfully be called a "call-by-X" behavior?) Clojure is adamantly call-by-value with its lazy evaluation, is there any particular reason why another language couldn't have the same lazy evaluation semantics as Clojure but support call-by-reference? pdw elsewhere in this thread suggests this whole "call-by-X" issue is pointless once you bring in lazy evaluation, I don't think that's a bad assessment.

If you don't accept that, then lots of other things become difficult to understand and explain as well. For instance, what do you call the thing that gets stored in a list? It's clearly not the object value itself, because that would preclude two lists from containing the same object.

I think the author of the article is a little confused about C++ as well, or perhaps just doesn't have a firm enough handle on it to be able to articulate the distinction between a location in memory and the value at a location in memory.

First, let's acknowledge that the context we're discussing is explaining to someone new to Python how Python works with function arguments.

Now, if someone asks if lead-acid batteries work using chemistry, and you say "they use physics", then they will probably end up with a fairly inaccurate picture of how lead-acid batteries work. What you've told them is technically correct, but it isn't practically useful.

It is the same if someone asks how Python passes arguments to functions and you say "it's pass-by-value". You've told them something technically correct, but they're going to think inaccurate things like that passing an object to a function copies all of the object's properties like a struct in C.

Even if you say "it's pass-by-value but the values are not what you think", you haven't actually added to their understanding by that phrase. You're better off explaining conceptually how it works, describing it as "call-by-sharing", and then explaining what that means. It will signal their brain to allocate space for a new concept, and not to drag in erroneous ideas from existing concepts. After they understand how it works, you can explain that call-by-sharing is actually just a spoonful of sugar to help the call-by-value go down.

Here's the thing: words are there to help us communicate. If you use a word in a way that is technically correct but conveys the wrong idea to your listener, you're doing it wrong.

Here's the other thing: this is computer science. In computer science, as in all math, you often encounter a concept that is "really just" some other concept. When you come to that realization about a concept that you understand superficially, it can be transformative, taking you to a deeper level of comprehension. When someone asks you about the concept, you'll want to share that deep comprehension with them, so it's natural to want to jump right into it and explain it by connecting it to the general case. But they will not understand if you do that.

You can't teach someone addition by starting with ring theory, after all.

The concepts of call-by-value vs call-by-reference are simple and easy to distinguish once somebody has understood this basic concept in languages. I don't mean to disregard newcomers, though. And in-fact I think that it is doing a disservice to them to make python sound like it is radically different and more complicated than other languages. Instead I think a newcomer is best served by helping them grasp basic, common language concepts as they apply to python as well as other languages.

I really also need call out that there seem to be a lot of inaccuracies with regards to other languages than python on this thread and even some confusing terminology and analogies by the article's author. Specifically there seem to be a lot of misunderstandings about C (and even C++) flying around and being perpetuated here.

For example, you compared passing a python object to passing a struct in C. Passing a C struct to a function does _not_ copy all the fields of the struct. It passes a reference (pointer) to the function, which the function then uses to access the fields (or properties if you will) in the struct directly at their original location in memory.

You do get automatic copies of primitive numeric types when you pass them to functions in C. The reasoning and distinction is pretty simple: they fit in hardware registers.

But, a struct, an array, or a string (or character array) is always going to be passed as a pointer. When you pass it to a function, the only way you get a copy of it is if you explicitly copy the value to a new location in memory and point to it. You can of-course also pass a pointer to a numeric value to a function as well (as in func(int *var)) instead of the actual value (as in func(int var)), in which case the same semantics apply.

personally, i find it confusing and near useless. but then i don't need to read some blog entry to understand python's semantics. so this really isn't about me.

again: this is a cultural thing, from c.l.p. - it apparently works well for them.

Then I think you may have forgotten what it's like to move to a call-by-sharing language for the first time.

>Passing a C struct to a function does _not_ copy all the fields of the struct. It passes a reference (pointer) to the function, which the function then uses to access the fields (or properties if you will) in the struct directly at their original location in memory.

I'm sorry, but everything you said there is wrong. Try it out for yourself: https://gist.github.com/4073329

first shot: ~ gcc -o foo -ggdb foo.c foo.c: In function ‘main’: foo.c:31: error: ‘flippedPoint’ undeclared (first use in this function) foo.c:31: error: (Each undeclared identifier is reported only once foo.c:31: error: for each function it appears in.)

Typo fixed: s/flippedPoint/secondPoint

what's the output?

    "{1, 2}{-1, -2}"

But, actually we're both wrong... and right? The real answer turns out to be a bit more complicated. In your example the copies are made (automatically) in the caller (main) which actually passes a pointer to flipPoint. Try disassembling your executable. You'll see what I mean.

>But, actually we're both wrong... and right? The real answer turns out to be a bit more complicated. In your example the copies are made (automatically) in the caller (main) which actually passes a pointer to flipPoint. Try disassembling your executable. You'll see what I mean.

I'm really not sure that what the assembly code does is relevant. First off, once it's in assembly, the concepts of "caller" and "function" are gone completely. There are structures that correspond to what compilers typically emit when you define and call functions, but there is no "copy in the caller and pass a pointer to the function". There's just "copy this data on the stack, put the location into a register, and then jump to this location".

Furthermore, this is looking at implementation details, and what we're concerned here with are the abstract concepts of how these languages work. If you look at the assembly, you're seeing how your compiler decided to handle it. If you have optimization on, flipPoint is going to be inlined anyway. The spec doesn't really care how the compiler achieves the result as long as it does achieve the correct result. One compiler might have it copy before jumping and pass a pointer, but another compiler could just as easily pass a pointer before jumping and then have the copy made after the jump. You would not know the difference.

But the way C acts is as if the fields of the struct were being copied when they were passed to the function.

The output of {-1, -2} is because it returned the other point by value. The first point is unmodified, which is why it prints out {1, 2}. If the value was being passed as a reference, the output would be {-1, -2}{-1, -2}.

Edit: "If the value was being passed as a reference" is sort of a weird thing to say. What I meant, of course, was "if the struct was being passed as a reference".

But if they come to you with "Is Python call-by-value or -reference?", then for the sake of getting them to break away from those contexts, I think your best bet is to say "neither", which is technically-but-not-practically slightly inaccurate.

You could try saying "It's technically call-by-value but you seriously need to forget everything about call-by-value in this context until I explain it to you," but depending on how their mind works, they may be looking for the connection to call-by-value the whole time you explain it (certainly that's what my mind would do if it were explained that way). And that's just a distraction.

So as long as you tell them at the end, "OK, so technically I lied earlier; this is call-by-value, but that's not how it's understood conceptually", I think the marginally inaccurate route is better.

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

    p = Person()

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

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?

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.

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.

In C terms, I think of all objects (including primitives such as numbers) as a struct with a void* pointer that holds the actual data, and another field that describes how to interpret the data: struct Obj { void* data; ObjDesc descr; }

Whenever you do objA=objB you create an new struct Obj with objA.data == objB.data. The same things happens when you pass an object to a function: you create a copy of the Obj.

When you modify an Obj, two things can happen: if the Obj is immutable you change where void* data points to: n1 = 4 n2 = b1 n1 = 5 ==> n1.data != n2.data

On the other hand, if Obj is mutable, than you don't change void* data, you modify the memory pointed to by data: n1=[] n2=n1 n1.append(1) ==> n1.data == n2.data

Is this correct or is mental model going to bite me sometime?

I don't mean to criticize. I think the best advice is to read K&R C again. And, as some other posters have suggested, take a look and at least a passing understanding of the memory model and assembly code generated by C/C++ compilers.

You'll see, for instance, that type information is not stored as a field in a C struct at all, it's purely a distinction for the compiler to use. A C struct, indeed any type of data in C, is _just_data_ in memory. At the machine level, there's no such thing as a type. Just registers, memory, and instructions. The compiler uses type information to generate the right instructions to handle the type.

And to clarify, type metadata _as_actual_data_ can exist in higher level languages, but it's definitely not a C thing.

If we have to keep it, I vote for Kent Pitman's suggestion of "call by identity". (I can't find the reference right now.)

http://en.wikipedia.org/wiki/Poes_law

As for Python being bizarre, it's just call-by-value, as has been pointed out elsewhere. The only arguably bizarre part is that all values must be pointers to objects. But I target like that consistency. I prefer it to Java, where I always have to think about whether a variable is an object pointer or a primitive type.

1. Some objects are immutable.

This makes some calls seem to be call-by-value, but they are not. A simple look at the generated code makes this obvious. Integers, strings, tuples, ... are passed by reference. It's just that you can't mutate the object being passed.

2. The behaviour of the assignment operator is different from most non-functional language.

In Python, assignment never mutate values. It assign a new reference to the 'variable' (i.e. the scoped name). This explains clearly why in functions, you can't mutate an immutable object even though it is passed by reference: assignment merely rebind the argument name to a new value.

That is why when you want to mutate something in a function in Python, your only recourse is to call a function on that object:

  i = 4
  s = 'George'
  l = [ 'me', 'you']
  foo (i, s, l)

  def foo(a, b, c):
    a = 3
    b = 'Mark'
    c.append( 42 )
    c = [ 2, 1 ]

  print(i, s, l)
  # prints 4, 'George', ['me', 'you', 42]

  def grow(array):
    array.append(1)

  array = []
  grow(array)

    #include <iostream>
    void swap(int &x, int &y) {
      int temp = x;
      x = y;
      y = temp;
    }
    int main() {
      int a = 3;
      int b = 4;
      std::cout << a; // 3
      std::cout << b; // 4
      swap(a, b);
      std::cout << a; // 4
      std::cout << b; // 3
    }

For the example code C++ given:

    string some_guy = "Fred";
    // ...
    some_guy = "George";

    In the above, the variable some_guy refers to a location in
    memory, and the value 'Fred' is inserted in that location (indeed,
    we can take the address of some_guy to determine the portion of
    memory to which it refers). Later, the contents of the memory
    location referred to by some_guy are changed to 'George'. The
    previous value no longer exists; it was overwritten. This likely
    matches your intuitive understanding (even if you don't program in
    C++).

A. "the variable some_guy refers to a location in memory, and the value 'Fred' is inserted in that location" Not true. The variable some_guy refers to a location in memory, but that location contains a pointer to a region of memory with the value "Fred". More on this in a bit.

B. "indeed, we can take the address of some_guy to determine the portion of memory to which it refers". Again, not true in the way the author probably intended. The address of 'some_guy' will be the address on the stack where the variable is located. The value at that address on the stack will be a pointer to a separate region of memory containing "Fred".

C. "Later, the contents of the memory location referred to by some_guy are changed to 'George'." To be precise, the contents of the memory location referred to by some_guy are changed to a new pointer to a different region of memory containing "George".

D. "the previous value no longer exists; it was overwritten." The values "Fred" and "George" exist through the entire lifetime of the program. They are string constants, which are compiled in to the data section of the program binary. The author is correct on one point: the value of 'some_guy' is overwritten during the reassignment. However, the value in this case is simply a pointer, not a string.

We can verify my claims experimentally. On my system (Ubuntu 11.04 32-bit, g++ 4.5.2), I wrote the following test program:

    //a.cpp
    #include <string>
    using namespace std;
    int main()
    {
      string some_guy = "Fred";
      some_guy = "George";
      return 0;
    }

Now, we can disassemble the "main" function to see exactly what is going on in the executable:

   $ objdump -d a
   a:     file format elf32-i386
   ...
   08048614 <main>:
    8048614:	55                   	push   %ebp
    8048615:	89 e5                	mov    %esp,%ebp
    8048617:	83 e4 f0             	and    $0xfffffff0,%esp
    804861a:	53                   	push   %ebx
    804861b:	83 ec 2c             	sub    $0x2c,%esp
    804861e:	8d 44 24 1f          	lea    0x1f(%esp),%eax
    8048622:	89 04 24             	mov    %eax,(%esp)
    8048625:	e8 06 ff ff ff       	call   8048530 <_ZNSaIcEC1Ev@plt>
    804862a:	8d 44 24 1f          	lea    0x1f(%esp),%eax
    804862e:	89 44 24 08          	mov    %eax,0x8(%esp)
    8048632:	c7 44 24 04 80 87 04 	movl   $0x8048780,0x4(%esp)
    8048639:	08 
    804863a:	8d 44 24 18          	lea    0x18(%esp),%eax
    804863e:	89 04 24             	mov    %eax,(%esp)
    8048641:	e8 ca fe ff ff       	call   8048510 <_ZNSsC1EPKcRKSaIcE@plt>
    8048646:	8d 44 24 1f          	lea    0x1f(%esp),%eax
    804864a:	89 04 24             	mov    %eax,(%esp)
    804864d:	e8 ce fe ff ff       	call   8048520 <_ZNSaIcED1Ev@plt>
    8048652:	c7 44 24 04 85 87 04 	movl   $0x8048785,0x4(%esp)
    ...

    8048632:	c7 44 24 04 80 87 04 	movl   $0x8048780,0x4(%esp)

    8048652:	c7 44 24 04 85 87 04 	movl   $0x8048785,0x4(%esp)

    $ objdump -s -j .rodata a
    a:     file format elf32-i386
    Contents of section .rodata:
     8048778 03000000 01000200 46726564 0047656f  ........Fred.Geo
     8048788 72676500 00000000                    rge.....

This means that our variable "some_guy" really is a pointer, and nothing more. The strings "Fred" and "George" are statically allocated in the data section of the binary, meaning they stick around indefinitely.