experts disagree on "call-by-reference"

[David Goodger]

on 2000-07-30 18:20, Greg Weeks (weeks at golden.dtc.hp.com) wrote:
> All of the passages mentioned above could just as well apply to Python.
> The experts are in explicit disagreement.

You're comparing apples with oranges. Of course they're "in disagreement",
because they're describing different things.

In compiled low-level languages, a variable is a symbol representing an
address in memory, and you can have read-write access to that address. For
local variables, the "address in memory" is actually an offset from the top
of the stack. In languages like C, the variable name doesn't survive the
compilation process; it is replaced by the address or stack offset directly.

In some high-level languages, like Python, the variable name survives to
runtime. In Python, a variable is a name in a namespace, implemented as a
dictionary. The name is a dictionary key to what evaluates internally to an
address of some sort (it doesn't matter what sort). For immutable objects,
you *don't* have write access to this address, just to the name itself. So
if you assign to a name/variable, you replace the address with a new one
(and the object at the old address may go away, if no other name is
referring to it). Mutable objects contain referemces of their own. Modifying
a list in-place means inserting, removing, or replacing references with new
ones. The referred-to objects themselves aren't changed in any way.

When passing a name to a function, you are simply assigning the "reference"
to a new name in the function's local namespace. Whatever you could do with
the old name before calling the function, you can do with the new name
inside the function. But the new name doesn't know anything about the old
one; assigning to the new name does *nothing* to the old name. Modifying an
object in-place will of course survive the function as a side-effect, but
the original *name* was not affected in any way.

Terms like "pass by reference" don't really apply to Python in the
traditional sense, because we're dealing with a higher order of
variables/names. (Of course, there are a few gotchas, as with any variable
or parameter passing scheme.) The language takes care of all the
housekeeping, freeing the programmer from having to deal with the details.
Once you understand the process and get over the need to keep track of all
the details, once you stop insisting that Python be explicable in terms of
some other language, once you trust the language to know what it's doing,
Python is very liberating. If you're a micromanaging control freak, then
perhaps Python isn't for you. But if you're willing to delegate the
drudgework, Python is great.

That's what's cool about different programming languages, just as with
natural languages: learning a new language shows you a new way of thinking.
Learning the syntax isn't enough; you have to embrace the deeper meaning.
And trying to apply some other language's semantics to a new language means
you'll speak haltingly, not fluently.

I hope this explanation helps, and I hope that this discussion fizzles out.
Life is too short!

-- 
David Goodger    dgoodger at bigfoot.com    Open-source projects:
 - The Go Tools Project: http://gotools.sourceforge.net
 (more to come!)