Is 'everything' a refrence or isn't it?

[Bryan Olson]

Bryan, I'll admit that I'm no C/C++ programmer, and I frequently assume
that if X is true for C++ it is also true for C, and vice versa. I
appreciate being corrected when I make a mistake.

However, in this case, I think you are confused by the term references.

No, though I should have had "references" in quotes; C doesn't
call anything a reference, so saying it confuses people about
what references are doesn't make sense.

[...]

I'll admit that my position on this question has changed. I no longer say
that "everything in Python is a reference" is *false*, not in the weak,
generic sense.

Of course it's false. Is indentation a reference? Is a comment
a reference? The bad term there is "everything", not "reference".

> How can it be? In the generic sense, Python names are
references. (Under the hood, names may even be implemented as C++
references for all I know.) I will still argue that the term reference is
harmful, not because it is technically incorrect, but because it activates
incorrect mental models of Python's high-level behaviour in too many
people.

Mike wrote that lists contain references. You said that was
nonsense as they contain objects. His description was right and
consistent with Python behavior. Yours was wrong and inconsistent
with Python behavior. List storing references is the *right*
mental model.

Perhaps you should check out the beginning of the thread before making
any additional comments. It wasn't me who was confused and asked "Hey
what's going on? I was told everything in Python is a reference, but when
I do this it doesn't work." I'm not projecting anything on anyone.

Read more carefully. His problem was in understanding variable
assignment in C versus Python: storage in a location versus name
binding. He got some good explanations. Unfortunately there was
also quite a bit of wrong reporting, which some of us are trying
to correct.

 

[Alex Martelli]

assignment semantics that differ from languages such as C++ and Java,
not the calling mechanism. In C++, assignment means copying a value. In
Python, assignment means reassigning a reference.

And in Java, it means just the same as in Python (with some unfortunate
exceptions, in Java, for elementary types such as int -- but for all
normal types, the meaning of assignment and parameter passing is just
the same in Java as in Python).

Considering that Java may have become the language most used for first
courses in programming, it's unfortunate to propagate disinformation
about its assignment semantics differing from Python's -- it will
confuse people who know Java, and there are many of those.


Alex

 

[Fredrik Lundh]

Wrong. C does not have references

Unless they've changed it since the drafts, the ANSI C specification uses
the word "reference" to describe how pointers work:

A pointer type describes an object
whose value provides a reference to an entity of the
referenced type. A pointer type derived from the
referenced type T is sometimes called ``pointer to T''.
The construction of a pointer type from a referenced
type is called ``pointer type derivation''.

so unless you're using some odd dialect of C that doesn't support pointers,
your C implementation sure has references.

and the Python use is consistent with the rest of computer science.

The problem isn't the word "reference" in itself, the problem is when people
are implying that "since Python passes object references to functions, it's
using call by reference".

In ordinary CS, "call by reference" generally means that the function is
handed a reference to the *variable* holding the *value*. You can do
this explicitly in C (by passing in &arg instead of arg), and you can do
this in C++, but there's no way to do this in Python -- Python variables
hold objects, not values.

Saying that Python uses "call by value" is probably more correct (where
the values are references), but that's even more confusing. (see endless
earlier threads for more on this).

That would be a terrible thing to do. Just learn to use the
meaning accepted in the discipline, and used in the Python doc.

afaik, the Python Language Reference never defines the word "reference".

It carefully defines words like "object" and "value", though, and terms like
"call by object" or "call by object reference" are perfectly understandable
if you use the words as they are defined in the language reference.

</F>

 

[Terry Hancock]

From what I can tell, Liskov proposed *three* different
names for
passing references to objects: call-by-sharing,
call-by-object, and call-by-object-reference.

"Call by object reference" makes the most sense to me. Names
in Python are object references: they refer to objects. You
might almost say "call by name" but that sort of implies
that you are passing the strings around (which is generally
untrue), and it doesn't convey what happens when the name is
something complex like "ham['spam'][0].eggs()[42]" (i.e.
"name" carries the conotation of being a simple string,
although you could argue that it doesn't have to mean that).

 

[Mike Meyer]

So very unlike "call by reference", right?

Right. All references are objects, so "call by object" includes all
the possibilities of "call by reference" as a subset. Not all objects
are references, so "call by reference", so it's a proper subset.

<mike

 

[Mike Meyer]

In ordinary CS, "call by reference" generally means that the function is
handed a reference to the *variable* holding the *value*.

That's the strictest definition of "call-by-reference". It's got a
major problem in that it means doing (with C syntax) "foo(&l[23])"
isn't CBR, because I didn't pass a reference to a *variable*. For
Python to be CBR, you have to use a broad definition of CBR

Saying that Python uses "call by value" is probably more correct (where
the values are references), but that's even more confusing.

I wouldn't say 'more correct', because of the above. But since *all*
paramater passing mechanisms pass a value of some kind - even
call-by-substitution - they're all call by value with that
definition. That makes the phrase pretty much useless.

The problem is that CBR and CBV were defined for langauges with
variables that had addresses, and assignments that copied values into
those addresses. The definitions were stretched by various groups to
fit their language, and some of the definitions disagree about edge
cases. The calling mechanisms of languages that have variables that
are bound to objects are all edge cases.

<mike

 

[Mike Meyer]

"Call by object reference" makes the most sense to me. Names
in Python are object references: they refer to objects. You
might almost say "call by name" but that sort of implies
that you are passing the strings around (which is generally
untrue)

"Call by name" has a specific meaning that is different from passing
strings around. CBName (and CBNeed) is generally implemented by
passing thunks. In Python, you could do CBN by passing tuples of
(string, globals(), locals()) around - which probably makes enough
noise when it hits the stack to qualify as a thunk.

<mike

 

[Aahz]

[contextectomy, because this quote makes no sense with or without
context]

Right. All references are objects, so "call by object" includes all
the possibilities of "call by reference" as a subset. Not all objects
are references, so "call by reference", so it's a proper subset.

Wrong. All references are *to* objects, maybe. There are no objects
that "are" references -- objects may *contain* references. You're
losing sight of the fact that objects and references are really two
completely different things in Python.

 

[Anders Hammarquist]

The problem isn't the word "reference" in itself, the problem is when people
are implying that "since Python passes object references to functions, it's
using call by reference".

Actually, I think the problem is not in the "call" bit. Python behaves
more or less like all other call by reference languages in the call. What
is confusing people is what happens when you *assign* to a function argument.

Those confused are expecting Python function arguments to behave just
like C++ references (which are just syntactic sugar for a dereferenced
pointer) or an Ada "in out" parameter when assigned. Python doesn't,
because in Python assignment assigns a new reference to the name,
rather than changing the referenced object.

/Anders

 

[rurpy]

afaik, the Python Language Reference never defines the word "reference".

It carefully defines words like "object" and "value", though, and terms like
"call by object" or "call by object reference" are perfectly understandable
if you use the words as they are defined in the language reference.

The Language Reference's definition of "value" is a non-definition.
About "value" it says that it is one of the three things an object
has. It then says some values can change and talks about
mutable and immutable. But we don't know what *it* is that
is mutable or immutable (other that it's called a "value" and it
is something an object "has").

Further down the page it says that container objects may have
references that are part of it's value. Part? Which part? Part
of what? Is an attribute part of a value?

I started a list of python doc problems a while ago. Right
near the top is "object value defintion is useless".

As I've said before, the Language Reference is badly
broken and needs a major rewrite. I don't think it should
be recommended to anyone as a source of authorative
information (except possibly for syntax since it in mostly
a Syntax Reference right now.)

[I posted another version of this yesterday from Google
but it has not appeared so...]

 

[Patrick Maupin]

This is where we disagree. I think their understanding of references
is dead on. What's broken is their understanding of what variables are
and what assignments mean. Once you fix that, the rest falls into
place.

(Steven D'Aprano wrote

What you're advocating is intentionally misleading people to deal with
a symptom. I'd rather give them enough truth to deal with the disease.

I agree completely. I have personally "converted" around a half-dozen
or so coworkers to Python over the course of the last three or four
years. The conversion takes place in stages. Usually, I have written
a small script for them which they later want to enhance, so they come
to me for a tutorial session.

My initial 5-10 minute tutorial starts off with an explanation of
name-binding, including something like "a=[1,2,3]; b=a; a[1]=4; print
b; b=42; print a, b". Note that this also demonstrates the dynamic
nature of Python typing -- 'b' is not restricted to being bound to a
list merely because the first time it was bound was to a list.

Once they have that down, I describe "immutable" vs. "mutable". I
start off by explaining that of course integers are immutable because
you cannot change 1 into 5. I then explain (with examples) that,
additionally, in the language, strings are immutable (which does NOT
mean you cannot usefully manipulate them, just that, for example, in "x
= 'abc'; x = x + 'd'" the manipulation "x + 'd'" results in a
completely new string. (The attempted example x[1] = "d" also gets them
used to the exception reporting mechanism.)

I actually spend more time (of this 10 minutes!) on "immutable" vs.
"mutable" (including ancillary lessons) than I spend on anything else.
After showing that strings are immutable, I then explain that tuples
are a sort of immutable list. This usually elicits the question of why
such a thing is needed, which is a great segue into a minute or so
spent on dictionaries and their keys. (Dictionaries can occupy
additional time if the student recognizes that they are a good fit for
a pressing need.)

Only about the last 30 seconds or so is spent on function calling. I
explain that all parameters are passed by reference, but that
OBVIOUSLY, if the called function wants to alter the caller's object,
the referenced object must be mutable, because, JUST AS WITH C
POINTERS, the pointer to the object is passed by making a copy of it on
the stack, so there is no way that the callee can directly alter the
caller's own pointer to the object.

After this lesson, I send them back to look at their script with
information about the online docs and a standing offer to help them
over any rough spots. NOT ONE PERSON has ever been confused about the
parameter passing.

I have only given these tutorials to accomplished programmers, so my
opinion about teaching newbies is not as well-formed, but for a
C/C++/assembler programmer, the REAL question about parameters is "What
is pushed onto the stack?" They are capable of a high level of
abstraction, so all they really want to know "Is a COPY of the object
passed on the stack, or is a POINTER to the object passed on the
stack?"

With such an accomplished student, if the teacher described Python's
parameter passing as anything but "call by reference", it would lead
to confusion, and, ultimately, disrespect for the teacher.

Regards,
Pat

 

[Patrick Maupin]

This is where we disagree. I think their understanding of references
is dead on. What's broken is their understanding of what variables are
and what assignments mean. Once you fix that, the rest falls into
place.

(Steven D'Aprano wrote

What you're advocating is intentionally misleading people to deal with
a symptom. I'd rather give them enough truth to deal with the disease.

I agree completely. I have personally "converted" around a half-dozen
or so coworkers to Python over the course of the last three or four
years. The conversion takes place in stages. Usually, I have written
a small script for them which they later want to enhance, so they come
to me for a tutorial session.

My initial 5-10 minute tutorial starts off with an explanation of
name-binding, including something like "a=[1,2,3]; b=a; a[1]=4; print
b; b=42; print a, b". Note that this also demonstrates the dynamic
nature of Python typing -- 'b' is not restricted to being bound to a
list merely because the first time it was bound was to a list.

Once they have that down, I describe "immutable" vs. "mutable". I
start off by explaining that of course integers are immutable because
you cannot change 1 into 5. I then explain (with examples) that,
additionally, in the language, strings are immutable (which does NOT
mean you cannot usefully manipulate them, just that, for example, in "x
= 'abc'; x = x + 'd'" the manipulation "x + 'd'" results in a
completely new string. (The attempted example x[1] = "d" also gets them
used to the exception reporting mechanism.)

I actually spend more time (of this 10 minutes!) on "immutable" vs.
"mutable" (including ancillary lessons) than I spend on anything else.
After showing that strings are immutable, I then explain that tuples
are a sort of immutable list. This usually elicits the question of why
such a thing is needed, which is a great segue into a minute or so
spent on dictionaries and their keys. (Dictionaries can occupy
additional time if the student recognizes that they are a good fit for
a pressing need.)

Only about the last 30 seconds or so is spent on function calling. I
explain that all parameters are passed by reference, but that
OBVIOUSLY, if the called function wants to alter the caller's object,
the referenced object must be mutable, because, JUST AS WITH C
POINTERS, the pointer to the object is passed by making a copy of it on
the stack, so there is no way that the callee can directly alter the
caller's own pointer to the object.

After this lesson, I send them back to look at their script with
information about the online docs and a standing offer to help them
over any rough spots. NOT ONE PERSON has ever been confused about the
parameter passing.

I have only given these tutorials to accomplished programmers, so my
opinion about teaching newbies is not as well-formed, but for a
C/C++/assembler programmer, the REAL question about parameters is "What
is pushed onto the stack?" They are capable of a high level of
abstraction, so all they really want to know "Is a COPY of the object
passed on the stack, or is a POINTER to the object passed on the
stack?"

With such an accomplished student, if the teacher described Python's
parameter passing as anything but "call by reference", it would lead
to confusion, and, ultimately, disrespect for the teacher.

Regards,
Pat

 

[Patrick Maupin]

This is where we disagree. I think their understanding of references
is dead on. What's broken is their understanding of what variables are
and what assignments mean. Once you fix that, the rest falls into
place.

(Steven D'Aprano wrote

What you're advocating is intentionally misleading people to deal with
a symptom. I'd rather give them enough truth to deal with the disease.

I agree completely. I have personally "converted" around a half-dozen
or so coworkers to Python over the course of the last three or four
years. The conversion takes place in stages. Usually, I have written
a small script for them which they later want to enhance, so they come
to me for a tutorial session.

My initial 5-10 minute tutorial starts off with an explanation of
name-binding, including something like "a=[1,2,3]; b=a; a[1]=4; print
b; b=42; print a, b". Note that this also demonstrates the dynamic
nature of Python typing -- 'b' is not restricted to being bound to a
list merely because the first time it was bound was to a list.

Once they have that down, I describe "immutable" vs. "mutable". I
start off by explaining that of course integers are immutable because
you cannot change 1 into 5. I then explain (with examples) that,
additionally, in the language, strings are immutable (which does NOT
mean you cannot usefully manipulate them, just that, for example, in "x
= 'abc'; x = x + 'd'" the manipulation "x + 'd'" results in a
completely new string. (The attempted example x[1] = "d" also gets them
used to the exception reporting mechanism.)

I actually spend more time (of this 10 minutes!) on "immutable" vs.
"mutable" (including ancillary lessons) than I spend on anything else.
After showing that strings are immutable, I then explain that tuples
are a sort of immutable list. This usually elicits the question of why
such a thing is needed, which is a great segue into a minute or so
spent on dictionaries and their keys. (Dictionaries can occupy
additional time if the student recognizes that they are a good fit for
a pressing need.)

Only about the last 30 seconds or so is spent on function calling. I
explain that all parameters are passed by reference, but that
OBVIOUSLY, if the called function wants to alter the caller's object,
the referenced object must be mutable, because, JUST AS WITH C
POINTERS, the pointer to the object is passed by making a copy of it on
the stack, so there is no way that the callee can directly alter the
caller's own pointer to the object.

After this lesson, I send them back to look at their script with
information about the online docs and a standing offer to help them
over any rough spots. NOT ONE PERSON has ever been confused about the
parameter passing.

I have only given these tutorials to accomplished programmers, so my
opinion about teaching newbies is not as well-formed, but for a
C/C++/assembler programmer, the REAL question about parameters is "What
is pushed onto the stack?" They are capable of a high level of
abstraction, so all they really want to know "Is a COPY of the object
passed on the stack, or is a POINTER to the object passed on the
stack?"

With such an accomplished student, if the teacher described Python's
parameter passing as anything but "call by reference", it would lead
to confusion, and, ultimately, disrespect for the teacher.

Regards,
Pat

 

[Patrick Maupin]

This is where we disagree. I think their understanding of references
is dead on. What's broken is their understanding of what variables are
and what assignments mean. Once you fix that, the rest falls into
place.

(Steven D'Aprano wrote

What you're advocating is intentionally misleading people to deal with
a symptom. I'd rather give them enough truth to deal with the disease.

I agree completely. I have personally "converted" around a half-dozen
or so coworkers to Python over the course of the last three or four
years. The conversion takes place in stages. Usually, I have written
a small script for them which they later want to enhance, so they come
to me for a tutorial session.

My initial 5-10 minute tutorial starts off with an explanation of
name-binding, including something like "a=[1,2,3]; b=a; a[1]=4; print
b; b=42; print a, b". Note that this also demonstrates the dynamic
nature of Python typing -- 'b' is not restricted to being bound to a
list merely because the first time it was bound was to a list.

Once they have that down, I describe "immutable" vs. "mutable". I
start off by explaining that of course integers are immutable because
you cannot change 1 into 5. I then explain (with examples) that,
additionally, in the language, strings are immutable (which does NOT
mean you cannot usefully manipulate them, just that, for example, in "x
= 'abc'; x = x + 'd'" the manipulation "x + 'd'" results in a
completely new string. (The attempted example x[1] = "d" also gets them
used to the exception reporting mechanism.)

I actually spend more time (of this 10 minutes!) on "immutable" vs.
"mutable" (including ancillary lessons) than I spend on anything else.
After showing that strings are immutable, I then explain that tuples
are a sort of immutable list. This usually elicits the question of why
such a thing is needed, which is a great segue into a minute or so
spent on dictionaries and their keys. (Dictionaries can occupy
additional time if the student recognizes that they are a good fit for
a pressing need.)

Only about the last 30 seconds or so is spent on function calling. I
explain that all parameters are passed by reference, but that
OBVIOUSLY, if the called function wants to alter the caller's object,
the referenced object must be mutable, because, JUST AS WITH C
POINTERS, the pointer to the object is passed by making a copy of it on
the stack, so there is no way that the callee can directly alter the
caller's own pointer to the object.

After this lesson, I send them back to look at their script with
information about the online docs and a standing offer to help them
over any rough spots. NOT ONE PERSON has ever been confused about the
parameter passing.

I have only given these tutorials to accomplished programmers, so my
opinion about teaching newbies is not as well-formed, but for a
C/C++/assembler programmer, the REAL question about parameters is "What
is pushed onto the stack?" They are capable of a high level of
abstraction, so all they really want to know "Is a COPY of the object
passed on the stack, or is a POINTER to the object passed on the
stack?"

With such an accomplished student, if the teacher described Python's
parameter passing as anything but "call by reference", it would lead
to confusion, and, ultimately, disrespect for the teacher.

Regards,
Pat

 

[rurpy]

Fredrik Lundh wrote:
....snip...

afaik, the Python Language Reference never defines the word "reference".
It carefully defines words like "object" and "value", though, and terms like
"call by object" or "call by object reference" are perfectly understandable
if you use the words as they are defined in the language reference.

It (sec. 3.1, "Objects, values and types") is not what I would
call a good definition . About values it says only

- that they are something that all objects have.
- they can be mutable or immutable.

It then has a few sentences about mutability, so after reading
it you will know that, whatever a value is, it can be changed
for some objects but not others. But what exactly it is that is
being changed is still a mystery.
Further down it talks about container objects "containing"
references to other objects and of those being part of it's
value. Part? What does it mean to contain? Can one
determine from reading this, if an attribute value is part
of the object's value? (I couldn't).

On my list on Python Doc problems that need fixing, is
"defintion of object values" and it has been on there
for nearly a year.

So I don't think referring people to the Language Reference
is a good way to help them understand Python. Python
badly needs a rewritten Language Reference.

 

[Donn Cave]

Quoth (e-mail address removed):
| Fredrik Lundh wrote:
| ...snip...
| > afaik, the Python Language Reference never defines the word "reference".
| > It carefully defines words like "object" and "value", though, and terms like
| > "call by object" or "call by object reference" are perfectly understandable
| > if you use the words as they are defined in the language reference.
|
| It (sec. 3.1, "Objects, values and types") is not what I would
| call a good definition . About values it says only
|
| - that they are something that all objects have.
| - they can be mutable or immutable.
|
| It then has a few sentences about mutability, so after reading
| it you will know that, whatever a value is, it can be changed
| for some objects but not others. But what exactly it is that is
| being changed is still a mystery.
| Further down it talks about container objects "containing"
| references to other objects and of those being part of it's
| value. Part? What does it mean to contain? Can one
| determine from reading this, if an attribute value is part
| of the object's value? (I couldn't).
|
| On my list on Python Doc problems that need fixing, is
| "defintion of object values" and it has been on there
| for nearly a year.

So you've had time to think about how you would define value, in a
few words. Any ideas?

I find the topic difficult, myself. I think you really have to apply
some context to the question, so there may not be any satisfactory
definition for the language reference.

But maybe it would be simple with the right focus. If we could somehow
define value, how would that help? I mean, presumably we need to
understand all this stuff because we want to write some software, and
if we dive in without understanding, our attempts will be plagued with
conceptual errors. Is there something about value in particular that
seems to be a problem here? ``No, you idiot, that's not a value -
THIS is a value!''

Donn Cave, (e-mail address removed)

 

[Antoon Pardon]

If we say "Python is call be reference" (or call by value, as many people
also say) we *know* the consequence will be newbies writing in saying "I
was told Python is call by reference, so I did this, and it didn't work,
is that a bug in Python? What is wrong?" It is not a bug in Python, it is
a bug in their mental model of how Python works, and we put that bug in
their head. Every time that happens, it is *our* fault, not theirs, for
using language guaranteed to mislead.

Well then I would think that the language that misleads is not
"reference" but assignment. Because it is not their idea of
call by reference that leads to the misconception, but their
idea of what an assignment does.

 

[rurpy]

Quoth (e-mail address removed):
| Fredrik Lundh wrote:
| ...snip...
| > afaik, the Python Language Reference never defines the word "reference".
| > It carefully defines words like "object" and "value", though, and terms like
| > "call by object" or "call by object reference" are perfectly understandable
| > if you use the words as they are defined in the language reference.
|
| It (sec. 3.1, "Objects, values and types") is not what I would
| call a good definition . About values it says only
|
| - that they are something that all objects have.
| - they can be mutable or immutable.
|
| It then has a few sentences about mutability, so after reading
| it you will know that, whatever a value is, it can be changed
| for some objects but not others. But what exactly it is that is
| being changed is still a mystery.
| Further down it talks about container objects "containing"
| references to other objects and of those being part of it's
| value. Part? What does it mean to contain? Can one
| determine from reading this, if an attribute value is part
| of the object's value? (I couldn't).
|
| On my list on Python Doc problems that need fixing, is
| "defintion of object values" and it has been on there
| for nearly a year.

So you've had time to think about how you would define value, in a
few words. Any ideas?

Not yet. The reason is that I am still trying to figure out
what a value is myself. Do all objects have values? If
not which do and which don't? What's the value of int(1)?
An object? Some otherwise unreachable thing that
represents the abstract concept of the number 1?
What the value of object()? A few weeks ago I turned
to that page for enlightenment, with the results I reported.

I find the topic difficult, myself. I think you really have to apply
some context to the question, so there may not be any satisfactory
definition for the language reference.

I have a hard time accepting that. I do not think there
is any aspect of human thought that cannot be described
by a sufficiently skilled writer.

But maybe it would be simple with the right focus. If we could somehow
define value, how would that help? I mean, presumably we need to
understand all this stuff because we want to write some software, and
if we dive in without understanding, our attempts will be plagued with
conceptual errors. Is there something about value in particular that
seems to be a problem here? ``No, you idiot, that's not a value -
THIS is a value!''

Yes, see above. How can you feel confident working with
things that aren't understood? (c.f. this thead about
problems resulting from python beginner's misconceptions
about references.)

 

[Bengt Richter]

Quoth (e-mail address removed):
| Fredrik Lundh wrote:
| ...snip...
| > afaik, the Python Language Reference never defines the word "reference".
| > It carefully defines words like "object" and "value", though, and terms like
| > "call by object" or "call by object reference" are perfectly understandable
| > if you use the words as they are defined in the language reference.
|
| It (sec. 3.1, "Objects, values and types") is not what I would
| call a good definition . About values it says only
|
| - that they are something that all objects have.
| - they can be mutable or immutable.
|
| It then has a few sentences about mutability, so after reading
| it you will know that, whatever a value is, it can be changed
| for some objects but not others. But what exactly it is that is
| being changed is still a mystery.
| Further down it talks about container objects "containing"
| references to other objects and of those being part of it's
| value. Part? What does it mean to contain? Can one
| determine from reading this, if an attribute value is part
| of the object's value? (I couldn't).
|
| On my list on Python Doc problems that need fixing, is
| "defintion of object values" and it has been on there
| for nearly a year.

So you've had time to think about how you would define value, in a
few words. Any ideas?

I find the topic difficult, myself. I think you really have to apply
some context to the question, so there may not be any satisfactory
definition for the language reference.

But maybe it would be simple with the right focus. If we could somehow
define value, how would that help? I mean, presumably we need to
understand all this stuff because we want to write some software, and
if we dive in without understanding, our attempts will be plagued with
conceptual errors. Is there something about value in particular that
seems to be a problem here? ``No, you idiot, that's not a value -
THIS is a value!''

IMO the problem is that our intuitive notion of value is ususally really of
an abstract value, like an integer value or a real or maybe a member of a finite
abstract set. But in programming we are always dealing with various concrete
representations of values, not values themselves. To get to a value, you have
to interpret the representation. To perform abstract operations, you have to
manipulate concrete representations, and guarantee that the resulting representations
really do represent the abstract results of the abstract operation.

People are so used to interpreting representations that they do it unconsciously.
Mostly the metonymic use of representations in discussing abstractions is a
taken-for-granted short cut for avoiding tiresome pedantry, but sometimes, I believe,
it lies at the heart of difficulties such as in trying to define value.

IMO the first step in defining "value" should be to declare that it always refers
to some abstract value, which is always an interpretation of some concrete representation.

I suspect that describing things in terms of abstract graphs and their transformations
would be useful. E.g., starting with python's objects (in the abstract) as nodes,
and "references" as directed arcs.

More on this later, perhaps, but I have to go now ...

Regards,
Bengt Richter

 

[Ben Sizer]

And in Java, it means just the same as in Python (with some unfortunate
exceptions, in Java, for elementary types such as int -- but for all
normal types, the meaning of assignment and parameter passing is just
the same in Java as in Python).

Considering that Java may have become the language most used for first
courses in programming, it's unfortunate to propagate disinformation
about its assignment semantics differing from Python's -- it will
confuse people who know Java, and there are many of those.

Yes, my mistake - I forgot that Java reseats object references rather
than copying object values. (I'm a C++ person at heart.)

Personally I think this is a reason why Java is a poor language to
teach beginners, as it's stuck between low level semantics from C and
high level semantics like those of Python. It doesn't provide a very
consistent view, meaning you're bound to get confused no matter what
second language you start to learn.