Finding the instance reference of an object : Python

Joe Strout wrote:
> On Oct 16, 2008, at 11:23 PM, Dennis Lee Bieber wrote:
[much blether]
>>> Side question, for my own education: *does* Python have a "ByRef"
>>> parameter mode?
>>>
>> As far as I'm concerned -- everything is "by ref" in Python...
>
> No, a "by ref" parameter would mean that this:
>
> def foo(ByRef x):
> x = x + [42]
>
> a = [1,2,3]
> foo(a)
>
> ...would result in a = [1,2,3,42]. You would only be able to pass a
> simple variable (not an expression or literal) to foo, and the 'x'
> inside foo would not be a local variable, but an alias of whatever
> variable was passed in. Thus any assignments to it would affect the
> original variable that was passed in.
>
In [8]: def foo(x):
...: x += [42]
...:

In [9]: a = [1, 2, 3]

In [10]: foo(a)

In [11]: a
Out[11]: [1, 2, 3, 42]

In [12]: def ffoo(x):
....: x.append(43)
....:

In [13]: ffoo(a)

In [14]: a
Out[14]: [1, 2, 3, 42, 43]

In [15]: def fffoo(a):
....: a = a + [42]
....:

In [16]: fffoo(a)

In [17]: a
Out[17]: [1, 2, 3, 42, 43]

So, is it call by reference or not? Does that depend on the
implementation of specific operators?

You problem seems to be that you ar still stuck with the notion of a
name as a reference to a specific area of memory. Which it's not,
excepting only if you want to consider the area of memory that holds a
reference to some value.

In the case of lists,

a = a + [something]

rebinds a, while

a += [something]

doesn't. So where does that leave you?

> But if Python has any such feature, I'm not aware of it. Certainly the
> default behavior is to pass everything (even object references) by
> value. Assignments made to them don't affect anything else.
>
>> Mutation of an object is never a bare LHS... It is either a method
>> call of the name
>>
>> alist.append()
>>
>> or a drill-down going inside the object
>>
>> alist[2] = something
>> anobject.attribute = something
>> adict["key"] = something
>
> Or, use of one of the compound operators like +=. That's the only real
> "gotcha" in Python to somebody coming from another language; you might
> naively expect that x += y is the same as x = x+y, but in Python this is
> not generally the case; instead += is a mutation operator, like the
> examples you show above.
>
Be careful though:

In [18]: a = 42

In [19]: id(a)
Out[19]: 14237932

In [20]: a += 1

In [21]: id(a)
Out[21]: 14237920

In [22]: a = []

In [23]: id(a)
Out[23]: 2140206636

In [24]: a += [42]

In [25]: id(a)
Out[25]: 2140206636

In other words, the behavior of augmented operations depends on whether
the reference is to a mutable or an immutable value.

>> But every language I've used (many: FORTRAN, C, C++, BASIC, VB,
>> Assembly, COBOL, Ada...) treats "variable" as "name of fixed location in
>> memory" and assignment to the variable means "replace the contents of
>> the location of memory associated with this name with the contents of
>> memory to which that name (may be anonymous in the case of an
>> expression) is associated by copying the contents from there to here"
>
> That's what Python does too. It just so happens that the fixed location
> in memory contains an object reference. No difference here between
> Python's object references VB.NET's object references, C++ pointers,
> Java object references, etc. etc.
>
>> Python, OTOH, ALWAYS handles assignment as "change the memory
>> association of this name to be the same as that name".
>
It might be simpler to say "Change this name to be a reference to that
value", or "Change this name to be a reference to the [result of
evaluating the] expression on the RHS".

Or indeed, "Change the content of that container element to be a
reference to the [result of evaluating the] expression on the RHS"

> What does that mean, exactly? It means: "replace the contents (i.e.
> object reference) of the memory location associated with this name with
> the contents (i.e. object reference) of the memory to which that name
> is associated by copying the contents from there to here."
>
> It's the exact same thing. (And exactly the same as in any other
> language.)
>
If you mean it's a reference assigment, of course it is. That's what he
was trying to say (I believe). But in C, for example,

int i;
i = 42;

actually stores the value 42 in the location associated with the name c.
Quite different from

int *i;
i = &42;

[Is that even valid C?] That's almost what Python does with

i = 42

>>> No, but if we define them in the standard way, and point out that
>>> Python variables behave exactly like variables in other languages,
>>> then that IS helpful.
>>>
>> But they don't...
>
> They really, really do.
>
>>> But it's not at all surprising with lists and dicts and objects --
>>> every modern language passes around references to those, rather than
>>> the data themselves, because the data could be huge and is often
>>> changing size all the time. Storing the values in a variable would
>>> just be silly.
>>>
>> In most all of those languages, one has to explicitly differentiate
>> the the difference between a copy and a reference.
>
> Only if you're thinking of languages from 20 years ago or more. Even in
> C++, while there is a different bit of kludgy syntax for object
> "references" (because they're mere pointers), it's the standard to use
> such pointers everywhere that objects are handled. Java cleaned up that
> kludginess by replacing the pointers with proper references, as did
> VB.NET, REALbasic, probably Ruby, and of course Python.
>
>> And even that is not
>> assured... As I recall, nothing in the Ada language reference forbids
>> implementing an "in out" procedure parameter from being implemented via
>> copy-in/copy-out semantics rather than via reference.
>
> Hah, well probably so. Ada even predates me, and I'm not all that young
> anymore!
>
>>> Hmm... I bet you're over 30. So am I, for that matter, so I can
>>> remember when people had to learn "pointers" and found it difficult.
>>
>> Bah... The roots of I/O in Pascal required pointer dereferencing.
>
> Hey, I remember Pascal... that was the language used on the Apple IIGS,
> back when I was in junior high. I also remember spending $800 for a
> 40MB hard drive for it. Ah, those were the days!
>
40 Mb! You were lucky! Etc., etc., [drools into beard.]

>>> So, if the semantics are all the same, I think it's helpful to use the
>>> standard terminology.
>>>
>> But, it seems, you are the only one arguing that "the semantics are
>> all the same"... Doesn't that suggest that they aren't the same?
>
> No, it suggests to me that there's a lot of confusion in the Python
> community. It appears as though people either (a) really want to
> think that Python's object handling is special and unique for emotional
> reasons, or (b) are comparing it to really ancient languages that didn't
> have any notion of objects and object references. This has led to
> making up new terminology and spreading confusion. I'm coming back to
> Python from almost a decade of working with other modern languages
> (including implementing the compiler for one of them), and I don't see
> any difference at all between Python's object handling and those.
>
Python's assignment semantics (as opposed to its "object handling, a
term for which I have no referent) are not the same as those of, say C.
I believe they are pretty much the same ass those of Icon, another
non-standard interpreted language.

There are close similarities between Python's names and C reference
variables, but the semantics are not exactly parallel.

People here don't describe Python as different just because they *want*
it to be different. Python acknowledges intellectual debts to many
languages, none of which is exactly like it.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

On Oct 17, 2008, at 2:36 PM, Steve Holden wrote:

>> No, a "by ref" parameter would mean that this:
>>
>> def foo(ByRef x):
>> x = x + [42]
>>
>> a = [1,2,3]
>> foo(a)
>>
>> ...would result in a = [1,2,3,42].
>>
> In [8]: def foo(x):
> ...: x += [42]
> ...:
>
> In [9]: a = [1, 2, 3]
>
> In [10]: foo(a)
>
> In [11]: a
> Out[11]: [1, 2, 3, 42]

This demonstrates that lists are mutable, and that += is a mutating
operator (and NOT an assignment).

> In [12]: def ffoo(x):
> ....: x.append(43)
> ....:
>
> In [13]: ffoo(a)
>
> In [14]: a
> Out[14]: [1, 2, 3, 42, 43]

Ditto (but for the .append method).

> In [15]: def fffoo(a):
> ....: a = a + [42]
> ....:
>
> In [16]: fffoo(a)
>
> In [17]: a
> Out[17]: [1, 2, 3, 42, 43]

And here, you're doing an assignment -- this is the only test of the
three that tests whether the parameter is passed by reference or by
value. The result: it's by value.

> So, is it call by reference or not?

Not.

> Does that depend on the implementation of specific operators?

No.

> You problem seems to be that you ar still stuck with the notion of a
> name as a reference to a specific area of memory. Which it's not,
> excepting only if you want to consider the area of memory that holds a
> reference to some value.

Which is exactly what it is, so that's what you should consider.

And my real point is that this is exactly the same as in every other
modern language. Nothing unusual here at all (except that some of us
here seem to want to make up new terminology for standard behavior,
perhaps in order to make Python seem more exotic).

> In the case of lists,
>
> a = a + [something]
>
> rebinds a

In standard terminology, it assigns a new value to a.

> while
>
> a += [something]
>
> doesn't.

Correct.

> So where does that leave you?

In exactly the same happy boat as Java, RB, .NET, etc. (even C++ if
you consider an object pointer to be the equivalent of an object
reference).

>> Or, use of one of the compound operators like +=. That's the only
>> real
>> "gotcha" in Python to somebody coming from another language; you
>> might
>> naively expect that x += y is the same as x = x+y, but in Python
>> this is
>> not generally the case; instead += is a mutation operator, like the
>> examples you show above.
>>
> Be careful though:
>
> In [18]: a = 42
>
> In [19]: id(a)
> Out[19]: 14237932
>
> In [20]: a += 1
>
> In [21]: id(a)
> Out[21]: 14237920

Good point -- obviously += can't mutate an immutable type. In those
cases it IS equivalent to an assignment. I can certainly see why
these operators can trip people up at first.

>> It's the exact same thing. (And exactly the same as in any other
>> language.)
>>
> If you mean it's a reference assigment, of course it is. That's what
> he
> was trying to say (I believe). But in C, for example,
>
> int i;
> i = 42;
>
> actually stores the value 42 in the location associated with the
> name c.

Yes, but let's get away from numbers, since those are a bit of a
special case, and not where the argument is revolving. (Since
Python's number-wrappers are immutable, they are behaviorally
equivalent to raw values, and so it really doesn't matter whether you
know that they're actually objects or not).

The discussion at hand is how best to explain and understand mutable
types. I don't remember C too well, but in C++ that'd be something
like:

Foo *x;
x = FooFactory();

This stores the address of the object FooFactory builds into x. It's
equivalent to what Python does with

x = FooFactory()

....except, of course, that Python's syntax is cleaner, and you don't
have all the rope that C/C++ gives you with which to shoot yourself in
the foot.

>> Hey, I remember Pascal... that was the language used on the Apple
>> IIGS,
>> back when I was in junior high. I also remember spending $800 for a
>> 40MB hard drive for it. Ah, those were the days!
>>
> 40 Mb! You were lucky! Etc., etc., [drools into beard.]



> Python's assignment semantics (as opposed to its "object handling, a
> term for which I have no referent) are not the same as those of, say
> C.

They are, though. The only difference you've pointed out is that
*numbers* are different in Python vs. C, and that's an internal
implementation detail I was blissfully unaware of until this
discussion. (I'm grateful to know it, but it really doesn't matter in
day-to-day coding.)

> I believe they are pretty much the same ass those of Icon, another
> non-standard interpreted language.

They're also the same as RB, Java, .NET... I'm hoping somebody who
knows some other modern OOP language (e.g. Ruby) will weigh in,
because I bet it's the same as those too.

Comparing it to C isn't really fair, because C isn't even an OOP
language. C++ would at least be in the same ballpark.

> There are close similarities between Python's names and C reference
> variables, but the semantics are not exactly parallel.

I agree; reference variables are an odd beast, most commonly used (and
most similar to) a ByRef parameter in modern languages. And it seems
that Python simply doesn't have that.

> People here don't describe Python as different just because they
> *want*
> it to be different. Python acknowledges intellectual debts to many
> languages, none of which is exactly like it.

Sure, nothing's exactly like it in all ways. But its object handling[*] is, in fact, exactly like every other modern OOP language.

Best,
- Joe
[*] Object handling: the ways in which objects are created, stored,
referenced, assigned, and passed into and out of method calls.

On 2008-10-17, Joe Strout <joe@strout.net> wrote:
> On Oct 17, 2008, at 2:36 PM, Steve Holden wrote:

>> You problem seems to be that you ar still stuck with the
>> notion of a name as a reference to a specific area of memory.
>> Which it's not, excepting only if you want to consider the
>> area of memory that holds a reference to some value.
>
> Which is exactly what it is, so that's what you should
> consider.
>
> And my real point is that this is exactly the same as in every
> other modern language.

No, it isn't. In many other languages (C, Pascal, etc.), a
"variable" is commonly thought of as a fixed location in memory
into which one can put values. Those values may be references
to objects. In Python, that's not how it works. There is no
"location in memory" that corresponds to a variable with a
particular name the way there is in C or Pascal or Fortran or
many other languages.

All that exists in Python is a name->object mapping.

> Nothing unusual here at all (except that some of us here seem
> to want to make up new terminology for standard behavior,
> perhaps in order to make Python seem more exotic).

That's because it is fundamentally different from what happens
in languages like C.

>> In the case of lists,
>>
>> a = a + [something]
>>
>> rebinds a
>
> In standard terminology, it assigns a new value to a.

The problem is that listeners from a C or FORTRAN background
will infer that there is a fixed region of memory named "a" and
"assigning a value to a" means writing that new value into the
region of memory named "a". Saying "rebinding" is a way of
helping people with backgrounds in non-dynamic languages that
there is no chunk of memory named "a" and that assigments
aren't doing the same thing they do in C or FORTRAN.

--
Grant Edwards grante Yow! My mind is a potato
at field ...
visi.com

On Oct 17, 2008, at 3:19 PM, Grant Edwards wrote:

>> And my real point is that this is exactly the same as in every
>> other modern language.
>
> No, it isn't. In many other languages (C, Pascal, etc.), a
> "variable" is commonly thought of as a fixed location in memory
> into which one can put values. Those values may be references
> to objects.

Right, though not in languages like C and Pascal that don't HAVE the
notion of objects. We really ought to stop bringing up those
dinosaurs and instead compare Python to any modern OOP language.

> In Python, that's not how it works. There is no
> "location in memory" that corresponds to a variable with a
> particular name the way there is in C or Pascal or Fortran or
> many other languages.

No? Is there any way to prove that, without delving into the Python
source itself?

If not, then I think you're talking about an internal implementation
detail.

> All that exists in Python is a name->object mapping.

And what does that name->object mapping consist of? At some level,
there has to be a memory location that stores the reference to the
object, right?

>> Nothing unusual here at all (except that some of us here seem
>> to want to make up new terminology for standard behavior,
>> perhaps in order to make Python seem more exotic).
>
> That's because it is fundamentally different from what happens
> in languages like C.

What happens in a modern OOP language is just as fundamentally
different (which is to say, not really very much) from what happens in
C or FORTRAN or COBOL, too.

But if there's any demonstrable difference between Python and any
other modern OOP language, I'd love to hear about it.

>>> a = a + [something]
>>>
>>> rebinds a
>>
>> In standard terminology, it assigns a new value to a.
>
> The problem is that listeners from a C or FORTRAN background
> will infer that there is a fixed region of memory named "a" and
> "assigning a value to a" means writing that new value into the
> region of memory named "a".

And they'd be correct. The value being written, in this case, as a
reference to some data that lives somewhere on the heap. Point that
out, and now their understanding is correct.

But if you instead say something like "all parameters are passed by
reference in Python," then the user gets the wrong idea. That
statement has a specific meaning which is, quite demonstrably, not true.

If you make up new terms like "rebinds," well, I guess at least that
avoids giving the listener the wrong idea. Instead it gives them no
idea at all, which may be better, but not as good as giving them the
right idea. It still leaves them to investigate what actually
happens, and ultimately they will find that the parameters are always
passed by value in Python. May as well save them the trouble and
point that out up front.

And how many recovering FORTRAN or C programmers do we get around
here, anyway? Java is what they've been teaching in school for the
last several years, and it was C++ for a good decade before that. The
semantics of Python (insofar as objects, assignments, and parameters
are concerned) are exactly the same as Java, and Java is just a
cleaned-up and streamlined C++. Even old-timers (like me) who learned
FORTRAN and COBOL way back in the day have long since moved on.

Best,
- Joe

On Oct 17, 4:03 pm, Joe Strout <j...@strout.net> wrote:
> On Oct 17, 2008, at 2:36 PM, Steve Holden wrote:
snip
> And here, you're doing an assignment -- this is the only test of the  
> three that tests whether the parameter is passed by reference or by  
> value.  The result: it's by value.
>
> > So, is it call by reference or not?
>
> Not.

But it's not by value, q.e.d.
snip

> ...except, of course, that Python's syntax is cleaner...

Excepting that thou then proceedst to 3.

snip

On Oct 17, 5:19 pm, Grant Edwards <gra...@visi.com> wrote:

> On 2008-10-17, Joe Strout <j...@strout.net> wrote:
>
> > And my real point is that this is exactly the same as in every
> > other modern language.
^^^^^^^^^

> No, it isn't. In many other languages (C, Pascal, etc.), a

^^^^^^^^^^^^^^^^^
Methinks the only real disagreement in this thread is what's a
"modern" language; Joe has made clear that he's not comparing Python
to C, Pascal or Fortran.

George

On Oct 17, 10:03 pm, Joe Strout <j...@strout.net> wrote:
> On Oct 17, 2008, at 2:36 PM, Steve Holden wrote:
>
[big snip]
> > I believe they are pretty much the same ass those of Icon, another
> > non-standard interpreted language.
>
> They're also the same as RB, Java, .NET... I'm hoping somebody who  
> knows some other modern OOP language (e.g. Ruby) will weigh in,  
> because I bet it's the same as those too.
>
[snip]
The difference is that Python uses dictionaries. When you write:

x = 42

what actually happens is something like:

globals()["x"] = 42

or:

locals()["x"] = 42

The name of the "variable" is a key in a dictionary with the value (a
reference to an object) that was "assigned" being the associated
value. When you "del" a "variable", eg del x, you're removing the
entry from the dictionary.

In Java the variables are like members in a struct (or fields in a
record in Pascal parlance) with the value that was assigned being its
content. (In Java there's also the detail that primitive types like
int are stored directly and not as references for reasons of speed.)

On Fri, 17 Oct 2008 15:39:33 -0600, Joe Strout wrote:

> On Oct 17, 2008, at 3:19 PM, Grant Edwards wrote:
>
>>> And my real point is that this is exactly the same as in every other
>>> modern language.
>>
>> No, it isn't. In many other languages (C, Pascal, etc.), a "variable"
>> is commonly thought of as a fixed location in memory into which one can
>> put values. Those values may be references to objects.
>
> Right, though not in languages like C and Pascal that don't HAVE the
> notion of objects. We really ought to stop bringing up those dinosaurs
> and instead compare Python to any modern OOP language.

You really should stop assuming that languages still in use are
"dinosaurs". There are many, many people whose understanding of such
terms as "call by value" or "variable" are based on C or Pascal or even
Fortran.

Besides, while the Pascal language itself doesn't have objects, plenty of
Pascal implementations do.


>> In Python, that's not how it works. There is no
>> "location in memory" that corresponds to a variable with a particular
>> name the way there is in C or Pascal or Fortran or many other
>> languages.
>
> No? Is there any way to prove that, without delving into the Python
> source itself?

>>> x = 1
>>> id(x) # a unique identifier, in CPython equal to its address
135536432
>>> x = 2
>>> id(x)
135536420

Notice that the address of x changes. Actually, that's a lie. The name
'x' doesn't have an address, except in the sense that the string 'x' must
occur somewhere in memory. But that's an unimportant implementation
detail. In reality, what we see is:

the object 1 is bound to the name 'x';
we ask for the id() of the object bound to 'x' (1), which is 135536432;
the object 2 is bound to the name 'x';
we ask for the id() of the object bound to 'x' (2), which is 135536420.

That's what is happening at the Python level of code. Anything else is
just implementation details.



> If not, then I think you're talking about an internal implementation
> detail.

Namespaces aren't an internal implementation detail, they are fundamental
to how Python works.


>> All that exists in Python is a name->object mapping.
>
> And what does that name->object mapping consist of? At some level,
> there has to be a memory location that stores the reference to the
> object, right?

Who cares? That's the *wrong* level. At *some* level, everything is just
flipping electrons from one state to another, but I think even you would
object if I claimed that:

"All computer languages are call-by-flipping-electrons, with no
exceptions."


Somebody could implement a Python interpreter using literal post-it notes
for names and literal boxes for objects. The fact that our CPUs are
optimized for flipping bits instead of (say) water flowing through tubes,
or clockwork, or punching holes in paper tape, is irrelevant. When
discussing what Python code does, the right level is to discuss the
Python virtual machine, not the implementation of that VM.

If you want to discuss the deeper levels, it's perfectly acceptable to
say that the CPython implementation uses memory locations holding
pointers. But that's not *Python*, that's hidden detail that the Python
programmer can't reach.



>>> Nothing unusual here at all (except that some of us here seem to want
>>> to make up new terminology for standard behavior, perhaps in order to
>>> make Python seem more exotic).
>>
>> That's because it is fundamentally different from what happens in
>> languages like C.
>
> What happens in a modern OOP language is just as fundamentally different
> (which is to say, not really very much) from what happens in C or
> FORTRAN or COBOL, too.

Which is why modern OOP languages like Python shouldn't use the same
terminology invented to describe what Fortran and Pascal do.


> If you make up new terms like "rebinds,"

This is not something that is just "made up", it is an actual description
of what the Python VM does.


> well, I guess at least that
> avoids giving the listener the wrong idea.

As opposed to call-by-value, call-by-reference, and "call-by-value-where-
the-value-is-the-reference", all of which do give the listener the wrong
idea.


> Instead it gives them no
> idea at all, which may be better, but not as good as giving them the
> right idea.

But it is the right idea. They just don't know what it means, because
they've been listening to people like you who insist on using Pascal
terminology with a definition unrecognizable to Pascal programmers. To an
ex-Pascal programmer like myself, when you talk about "call by value
where the value is a reference", it sounds to me as if you are insisting
that cars are ACTUALLY horse and buggies, where the horse is the engine,
why are we inventing new terms like 'automobile', that just confuses
people.



> It still leaves them to investigate what actually happens,
> and ultimately they will find that the parameters are always passed by
> value in Python.

But they aren't. When you call a function, the arguments are not copied
before being passed to the function.



> May as well save them the trouble and point that out
> up front.

Well, sure, if you want to be misleading and confusing.



> And how many recovering FORTRAN or C programmers do we get around here,
> anyway?

Enough.

It's not just people who have programmed Pascal, but those whose
understanding of CBV and CBR have been shaped by ancient half-remembered
Pascal lessons.


> Java is what they've been teaching in school for the last
> several years, and it was C++ for a good decade before that.

Have they really? Which school is that?

My company has hired a part-time young gun programmer. He's still at Uni,
doing Comp Sci, and has *far* wider IT experience than the average
programmer his age. His skills? PHP, Perl, C, oh and he's just starting
to learn C++ this semester.

There are plenty of programmers who have never been to university or
collage, and even some who have never learnt programming in school at
all. Believe it or not, it's not compulsory.



--
Steven

On Fri, 17 Oct 2008 16:36:24 -0400, Steve Holden wrote:

> People here don't describe Python as different just because they *want*
> it to be different. Python acknowledges intellectual debts to many
> languages, none of which is exactly like it.

I understand that Python's object and calling semantics are exactly the
same as Emerald (and likely other languages as well), and that both
Emerald and Python are explicitly based on those of CLU, as described by
by Barbara Liskov in 1979:

"In particular it is not call by value because mutations
of arguments performed by the called routine will be
visible to the caller. And it is not call by reference
because access is not given to the variables of the
caller, but merely to certain objects."

http://www.lcs.mit.edu/publications/...LCS-TR-225.pdf

quoted by Fredrik Lundh here:
http://mail.python.org/pipermail/pyt...ay/204379.html


"Call by object/sharing" isn't some new-fangled affectation invented by
comp.lang.python dweebs to make Python seem edgy and different. It's a
term that has been in use in highly respected Comp Sci circles for over
thirty years. In case anybody doesn't recognise the name:

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


--
Steven

On Fri, 17 Oct 2008 09:56:17 -0600, Joe Strout wrote:

> On Oct 16, 2008, at 11:23 PM, Dennis Lee Bieber wrote:
>
>> On Thu, 16 Oct 2008 21:19:28 -0600, Joe Strout <joe@strout.net>
>> declaimed the following in comp.lang.python:
>>
>>> Now that IS mysterious. Doesn't calling a function add a frame to a
>>> stack? And doesn't that necessitate copying in values for the
>>> variables in that stack frame (such as 'x' above)? Of course we're
>>
>> No -- it copies the /reference/ to the object containing the value.
>
> The reference to the object IS the value of an object reference
> variable.

That's a bizarre and unnatural way of looking at it. To steal a line from
the effbot, that's like valuing your child's Social Security number over
the child herself:

http://mail.python.org/pipermail/pyt...ay/204560.html


If we execute a line of Python code:

x = "parrot"

and then ask "What's the value of x?", I think that even you would think
I was being deliberately obtuse, difficult and obfuscatory if I answered
"location 0xb7cdeb2c".


> So good, parameters are passed ByVal in Python as they appear
> to be, and as is the default in every other modern language.

Nonsense. Python doesn't copy a parameter before passing it to the
function. You get the same parameter inside the function as outside:

>>> def foo(x):
.... print id(x)
....
>>> a = ['some', 'thing']
>>> print id(a); foo(a)
3083441036
3083441036


I'm going to anticipate your response here: you're going to deny that
call by value implies that the list ['some', 'thing'] will be copied
before being passed to the function. According to *some* definitions of
CBV, you might even be right. But according to *other* definitions,
including the one that I learned in comp sci at university, that copying
of data is an essential part of CBV.

These other definitions aren't necessarily a formal definition from some
Computer Scientist. They're just as likely to be informal understandings
of what CBV and CBR mean: "if it's call by value, don't pass big data
structures because they will be copied and your code will be slow".


>> Just as assignment transfers the reference to the RHS object to the
>> name
>> shown on the LHS.
>
> Assignment copies the RHS value to the LHS variable. In the case of an
> object reference, the value copied is, er, an object reference.

No, assignment binds an object to a name. That's what Python does.

Of course, at the implementation level, name binding might be implemented
by copying object references. Or it might not. That's an implementation
detail that isn't relevant at the Python level.

Or at least, it shouldn't be relevant until the abstraction leaks.
http://www.joelonsoftware.com/articl...tractions.html



[snip]
> For object references (including the mutable ones that may treat people
> up), Python's behavior is no different from any other language.

That's an exceedingly broad claim. No different from Java? Well, perhaps.
No different from Lisp? Doubtful. No different from Forth? Yeah, riiight.

Speaking of Java, there's one major difference between Java and Python
with respect to names. In a statically typed language like Java, you
define names before you use them, and from that point the name is bound
to both a type and an object. But the binding to the object is optional,
and such unbound names are said to be null.

In a dynamically typed language like Python, names are bound only to
objects. You can't have an unbound name: if a name exists, it must be
bound to an object, and if it doesn't exist, you get a NameError
exception when you try to access it. And objects are typed, not names.

http://www.ferg.org/projects/python_...e-by-side.html




>>>> (Answer: neither. They are call by name.)
>>>
>>> I have no idea what that means. They're call by value as far as I can
>>> tell. (Even if the value may happen to be a reference.)
>>
>> Technically, as I recall the definition of "call by name", they
>> aren't that either. ...
>> Call by name, then, acted as a macro expansion wherever the argument
>> was referenced in the called function.
>
> Thanks for that explanation. Clearly that's not what's going on in
> Python.

Ah no, that's my bad. I have a strange and disturbing mental stutter that
substitutes "call by name" when I mean to say "call by object" at the
most embarrassing times. Sorry.




--
Steven